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This  report  deals  with  the  problems  of  specification,  modeling,  and  enforcement  of  con¬ 
straints  in  databases.  The  active  database  area  is  emerging  as  a  viable  alternative  for 
implementation  of  large  scale  database  applications  particularly  those  involving  data 
that  needs  close  monitoring  and  control  due  to  its  dynamic  nature.  Applications  in 
monitoring  of  personnel,  equipment  materials  etc.  need  capabilities  available  in  modern 
database  systems.  The  entire  area  of  command  and  control  engineering  is  likely  to 
benefit  immensely  from  the  emerging  "active  database"  technology.  This  report  presents 
an  enhanced  conceptual  data  model  which  is  based  on  the  popular  entity  relationship  (ER) 
data  model.  This  model  has  been  enhanced  with  a  capability  of  modeling  active  database 
behavior  at  a  higher  level  than  the  event  condition-action  rules  used  in  other  systems. 

A  high  level  specification  language  is  presenting  and  then  showing  how  it  can  be  mapped 
into  the  facilities  of  an  active  commercial  DBMS  such  as  INGRES.  This  report  addresses 
three  different  types  of  constraints:  integrity  constraints,  the  invariant  properties  of 
the  model  as  constraints,  and  dynamic  constraints  that  deal  with  a  change  of  state  that 
occurs  during  update  operations.  The  facility  described  can  be  thought  of  as  a  part  of 
the  design  tools  that  are  needed  to  exploit  the  active  capabilities  in  a  database 
management  system.  The  specification  of  active  behavior  in  the  form  of  events  and 
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Section  1 

INTRODUCTION 


This  report  deals  with  the  problem  of  specification,  modeling,  and  enforcement  of  constraints 
in  databases.  The  active  database  area  is  emerging  as  a  viable  alternative  for  implementa¬ 
tion  of  large  scale  database  applications,  particularly  those  involving  data  that  needs  close 
monitoring  and  control  due  to  its  dynamic  nature.  Applications  in  monitoring  of  personnel, 
equipment,  materials  etc.  need  capabilities  available  in  modern  database  systems.  The  entire 
area  of  command  and  control  applications  is  likely  to  benefit  immensely  from  the  emerging 
“active  database”  technology. 

The  term  “active”  has  two  connotations:  first,  in  contrast  to  “passive,”  it  implies  that 
the  database  system  has  a  component  that  allows  it  to  actively  perform  changes  within  the 
database  ,  and  possibly  to  the  environment  consisting  of  other  data,  users,  and  equipment. 
The  second  connotation  can  be  traced  to  the  database  actively  offering  information  to  the 
user  whenever  information  of  interest  “happens,”  as  opposed  to  being  only  “reactive”  to  a 
user’s  request  whenever  the  user  presents  one.  It  is  also  possible  to  treat  the  “active”  nature 
of  a  database  as  being  equivalent  to  “dynamic”  or  changing  constantly.  This  contrasts  with 
the  typical  “static”  nature  of  a  database  where  data  tends  to  remain  constant  unless  changed 
explicitly  by  an  outside  intervention. 

The  currently  available  capabilities  in  database  management  systems  are  limited  ,  but 
are  likely  to  be  expanded  in  the  future  very  rapidly.  One  facility  is  known  as  triggers  which 
are  activated  upon  the  occurrence  of  certain  events,  and  which  automatically  cause  actions 
within  the  database.  For  example,  systems  like  SYBASE  or  INTERBASE  allow  triggers  to  be 
defined  and  have  a  similar  style  of  trigger  implementation.  But  the  facility  is  limited  by  the 
number  of  triggers  that  can  be  defined  to  go  with  a  relation,  or  the  level  of  nesting  possible. 
The  so-called  knowledge-management  extension  of  INGRES  allows  rules  to  be  defined  and 
prv-cedures  to  be  invoked  a^  a  result  of  the  firing  of  rules.  The  procedures  in  turn  may  give  rise 
to  new  rule  firings.  The  net  result  of  these  rules  and  triggers  shows  up  in  terms  of  changing 
some  data  values,  or  sending  some  control  signals  to  other  hardware  for  process  control  type 
of  applications,  or  sending  alerting  messages  to  human  decision  makers.  Both  the  trigger  and 
r\de  facilities  axe  quite  powerful  and  give  rise  to  the  so-called  “active”  nature  of  the  database 
system. 

Section  2  of  this  report  presents  an  enhanced  conceptual  data  model  which  is  based  on 
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the  popular  entity  relationship  (ER)  data  model.  We  have  enhanced  it  with  a  capability 
of  modeling  active  database  behavior  at  a  higher  level  than  the  event-condition-action  rules 
used  in  the  Sentinel  system  [Cha91].  We  have  also  proposed  a  diagrammatic  convention  to 
go  with  this  model  which  may  need  further  work  in  terms  of  implementing  a  diagramming 
and  conceptual  schema  editing  tool  based  on  it.  We  present  a  concise,  high  level  specification 
language  and  then  show  how  it  can  be  mapped  into  the  facilities  of  an  active  commercial 
DBMS  such  as  INGRES. 

Database  constrciints  are  inherently  declarative  and  can  be  classified  in  different  ways.  In 
section  3  of  this  report  we  address  three  different  types  of  constraints:  integrity  constraints, 
the  invariant  properties  of  tie  model  as  constraints,  and  dynamic  constraints  that  deal  with 
a  change  of  state  that  occurs  during  update  operations.  Our  contention  is  that  maintenance 
of  constraints  can  be  accomplished  by  deriving  appropriate  “active  database  behavior”  in 
the  conceptual  schema  that  are  translated  into  executable  rules  or  triggers.  These  rules  or 
triggers  cause  the  appropriate  “repairing”  process  that  takes  care  of  “fixing”  the  database  so 
that  it  is  consistent  with  the  constraints. 

The  facility  we  have  described  here  can  be  thought  of  as  a  part  of  the  design  tools  that  are 
nppried  to  exploit  the  active  capabilities  in  a  database  management  system.  The  specification 
of  active  behavior  in  the  form  of  events  and  rules  in  the  (ER)^  model  is  a  design  time  activity. 
With  a  mapping  tool  ,  these  are  mapped  into  the  actual  functionality  of  the  proposed  DBMS. 
In  future,  this  whole  activity  may  be  considered  to  be  a  function  of  the  mediator  which  is 
responsible  for  enforcing  constraints  that  the  user  specifies,  and  translating  them  to  system 
executable  rules  or  triggers.  The  (ER)^  model  may  be  considered  as  the  user’s  view  or 
“window”  on  the  underlying  active  database.  The  user  can  continue  to  manipulate  this  view 
with  the  help  of  a  possible  future  tool  for  (ER)^  schema  manipulation  and  editing.  The 
mediator  will  be  responsible  for  “reflecting”  these  changes  in  the  actual  DBMS. 

In  section  4  of  this  report  we  have  placed  this  work  in  proper  context  and  have  pointed 
out  a  large  number  of  possible  directions  for  extending  this  work. 
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Section  2 

(ER)2  model 


In  this  section,  we  propose  an  extension  to  database  conceptual  modeling  using  the  Entity- 
Relationship  (ER)  approach  to  incorporate  active  database  behavior  in  the  form  of  events 
and  rules. 

The  ideas  presented  here  have  first  been  delineated  in  [TNCK90,  TNCK91]  and  further 
developed  in  [Tan92].  As  the  basis  for  the  proposed  extension,  we  adopt  the  variant  of  the  ER 
model  used  in  the  Lawrence  Berkeley  Laboratory  (LBL)  tools  [SM91,  MF91]  that  includes 
generalization/specialization  and  full  aggregation  as  relationships  involving  relationships,  thus 
requiring  directed  arcs  in  the  ER  diagram  to  denote  inter-object  connections.  The  choice  of 
a  particular  variant  of  the  ER  model  does  not  disturb  the  incorporation  of  active  database 
behavior  in  the  conceptual  schema,  because  the  new  dimension  is  orthogonal  to  the  data 
abstractions  of  the  model. 

First,  we  define  '"e  concepts  of  events  and  rules,  and  present  a  syntajc  for  active  behavior 
specification  at  th  ,  conceptual  level  in  terms  of  events  and  rules  in  section  2.1.  Then  we 
describe  the  operational  semantics  of  the  language  in  section  2.2.  We  introduce  (ER)^  dia¬ 
grams  (ER  diagrams  with  events  and  rules)  in  section  2.3.  In  section  2.4  we  show  how  the 
active  behavior  specified  in  the  (ER)^  model  can  be  algorithmically  mapped  into  language 
constructs  at  the  relational  DBMS  level. 


2.1  Events  and  Rules  as  ER  objects 

In  the  ER  approach,  the  basic  objects  are  entities  and  relationships  that,  along  with  their 
attributes,  model  the  objects  of  the  real  world  and  their  properties.  Figure  2.1  shows  how 
these  concepts  are  viewed  in  a  meta-schema,  i.e.,  a  meta-ER-diagram  of  the  ER  model  itself. 
In  the  figure,  “ENTITY”  and  “RELATIONSHIP”  are  specializations  of  a  generic  meta-entity 
“ER-OBJECT”,  to  which  they  are  connected  by  ‘Ts_A”  arcs;  the  meta-entity  “ATTRIBUTE” 
is  identification  dependent  on  “ER-OBJECT”,  so  it  is  connected  to  “ER.OBJECT”  by  an 
“ID”  arc.  The  meta-relationship  “ER-Connection”  means  the  different  types  of  directed  arcs 
that  may  occur  between  ER  objects.  Possible  connections  are: 

•  Inter-entity  connections:  “Is_A”,  and  “ID”  arcs. 
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ER  CoAn«cttoft 


to(M) 


Figure  2.1:  Meta-ER-diagram  of  the  ER  Model 


•  Connections  between  entities  and  relationships  and  inter-relationship  connections:  as¬ 
sociation  arcs  showing  cardinality,  participation  constraints,  and  roles  of  the  partic¬ 
ipating  objects  (e.g.,  in  figure  2.1,  “from”  and  “to”  are  roles  of  “ER-OBJECT”  in 
“ER_Connection”,  while  “M”  means  the  cardinality  “many”  of  “ER_OBJECT”  in  “ER_- 
Connection”). 

In  our  approach,  we  view  the  real  world  as  constituted  by  entities,  relationships,  events 
and  rules,  all  primitive  objects  of  the  model.  While  entities  and  relationships,  along  with 
their  attributes,  represent  the  structural  aspects  of  the  information  system  being  modeled, 
events  and  rules  represent  the  active  behavior  that  controls  the  states  of  the  data  objects  and 
their  attributes.  We  call  the  resulting  model  as  the  Entity- Relationship  model  with  Events 
and  Rules,  or  (ER)^  model  for  short.  The  abstract  construct  that  extends  the  ER  model  has 
the  following  grammatical  form^: 

*We  use  a  BNF-like  notation  for  syntax,  where  non-terminals  are  denoted  in  italic  lower  case  letters,  while 
words  in  non-itaJic  lower  c3Lse  and  upper  case  letters  denote  terminals.  Single-quoted  characters  such  as 
are  terminal  delimiters  whereas  the  rest  are  meta-characters.  Square  brackets  [...]  are  used  to  denote  optional 
constructs,  and  the  notation  [...]*  denotes  zero  or  more  repetitions  of  the  enclosed  construct.  *(’  is  used  to 
delimit  alternatives  and  curly  braces  {  ...  }  denote  one  from  a  number  of  enclosed  alternatives. 
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behavior.definition  ;;=  behavior.sentence  [behavior. senttnct]' 
behavior. sentence  WHEN  event  FIRE  rule 

rule  ::=  rule.id  ['(’  description  ‘)’]  [  ‘[’  priorityJevel ']’  ] 
_ [IF  condition  THEN]  actionJist 


The  informal  interpretation  of  this  definition  is  quite  simple;  when  event  is  detected, 
the  corresponding  rule  is  fired,  which  means  that  condition  is  evaluated  and,  if  it  holds,  the 
associated  actions  in  actionJist  are  triggered.  Since  a  behavior.definition.  in  general,  consists 
of  many  behavior  .sentences,  the  execution  of  actions  in  one  rule  may  give  rise  to  new  events 
that  may  fire  other  rules. 

This  definition  encompasses  the  new  functionalities  that  have  been  added  into  DBMSs  in 
the  form  of  rule-like  constructs.  If  action.list  is  a  sequence  of  database  updates,  rule  functions 
as  a  “database  trigger”.  If  action.list  is  a  message  or  a  signal  that  is  dispatched  to  a  user  or 
an  application,  rule  functions  as  an  “event  alerter”.  W’e  could  even  consider  the  particular 
case  in  which  event  is  a  database  query  and  rule  is  a  deductive  rule.  In  this  report,  we  do  not 
address  the  application  of  this  framework  for  modeling  deductive  databases;  rather  we  will 
leave  it  for  further  research. 

Figure  2.2  shows  the  meta-ER-diagram  of  the  (ER)^  model.  In  the  figure,  the  two  new 
objects  of  the  model,  “EVENT”  and  “RULE”  are  incorporated  into  the  ER  model  as  spe¬ 
cializations  of  “ER2_0BJECT”.  Like  entities  and  relationships,  events  and  rules  may  have 
attributes  that  describe  their  properties.  Being  first-class  objects,  thev  may  be  connected  to 
each  other  and  to  other  objects  through  the  meta-relationship  “ER2.Connection”.  Possible 
connections  involving  events  and  rules  are: 

•  Inter-event  connections:  “Precedes”  referring  to  the  order  of  occurrence  of  events. 

•  Inter-rule  connections:  “Priority”  to  determine  the  order  of  execution  of  rules. 

•  Connections  between  events  and  rules:  “Fires”  between  an  event  and  the  associated 
rules.  “Raises”  between  a  rule  and  the  events  that  its  execution  gives  rise  to. 

•  Connections  between  events  and  entities/relationships;  “Affects”  meaning  that  an  event 
raised  by  the  execution  of  a  rule  may  affect  the  state  of  an  entity/relationship.  “.4f- 
fected_by”  meaning  that  an  entity/relationship  is  affected  by  the  occurrence  of  an  event. 

Some  of  these  connections  are  implicit  as  we  discuss  later  in  this  section.  For  example, 
♦^he  events  that  the  execution  of  a  rule  raises  are  the  result  of  the  actions  specified  for  that 
rule.  Also,  the  “Precedes”  connection  between  events  is  implicitly  defined  by  the  time  of 
occurrence  of  the  events,  and  does  not  need  to  be  explicitly  specified  in  the  (ER)^  schema. 

We  distinguish  between  event  classes  and  event  instances,  as  well  as  between  rule  classes 
and  rule  instances,  in  keeping  with  data  objects  (entities,  relationships)  which  have  classes 
(entity  sets,  relationship  sets)  and  instances.  However,  while  classes  and  instances  of  data 
objects  are  initially  bound  statically  (at  data  load  time),  classes  and  instances  of  events  and 
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Figure  2.2:  Meta-ER-diagram  of  the  (ER)^  Model 

rules  are  always  bound  dynamically  (at  transaction  execution  time).  For  example,  the  event 
“all  employees  working  on  project  Alpha  have  been  deleted”  is  an  instance  of  the  event  class 
“EMPLOYEE  deleted”;  they  are  bound  at  the  time  of  the  occurrence  of  the  event.  Note 
also  that  an  event  instance  does  not  correspond  necessarily  to  a  single  object  instance;  in 
general,  it  refers  to  a  set  of  object  instances  (in  the  example,  the  set  of  employees  working  on 
project  Alpha).  The  concept  of  rule  classes/instances  relates  to  that  of  event  classes/instances. 
In  the  same  example,  a  rule  that  is  fired  by  the  event  instance  “all  employees  working  on 
project  ALPHA  have  been  deleted”  is  an  instance  of  a  rule  class  whose  firing  event  class 
is  “EMPLOYEE  deleted”;  this  rule  class  may  have  different  instances  for  different  sets  of 
deleted  employees  (i.e.,  event  instances).  Classes  of  events  and  rules  are  specified  statically, 
along  with  the  (ER)^  schema;  as  we  pointed  out  before,  instances  are  determined  dynamically, 
at  transaction  execution  time,  i.e.,  at  event  occurrence  time.  As  with  entity  and  relationship, 
sometimes  we  will  be  using  the  terms  event  and  rule  ambiguously,  either  referring  to  (event 
and  rule)  classes  or  to  (event  and  rule)  instances.  Because  every  event  instance  is  a  unique 
occurrence  and  so  is  its  associated  rule  instance,  there  is  no  ambiguity.  The  context  determines 
whether  we  are  referring  to  classes  or  instances. 
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2.1.1  Events 


VVe  ube  the  concept  of  event  as  “the  actual  outcome  or  final  result"  [American  Heritage 
Dictionary,  Second  College  Edition,  page  170].  .\n  event  is  something  that  happens  at  a 
point  in  time,  and,  theoretically,  has  no  duration  [RBP'''91].  In  fact,  instead  of  unifying 
the  notion  of  action/event  as  commonly  found  in  the  literature,  we  distinguish  between  the 
occurrence  of  an  event  and  the  action  that  caused  it  (i.e.,  events  occur  when  the  associated 
actions  have  been  executed  by  some  agent).  For  example,  the  action  "update  balance"  causes 
the  occurrence  of  the  event  “balance  updated".  An  action  is,  in  general,  denoted  by  a  verb 
in  imperative  form;  its  execution  takes  time.  However,  an  event,  in  general,  is  denoted  by  a 
verb  in  past  participle  tense,  and  its  occurrence  is  just  a  point  in  time.  This  distinction  is 
fundamental  for  the  approach  we  propose. 

Events  may  logically  precede  or  follow  one  another  or  may  be  unrelated.  There  are  two 
types  of  ordering  of  events  to  be  considered:  a  causal  ordering  and  a  temporal  ordering. 
The  first  one  relates  events  of  different  types  (e.g.  the  event  “flight  .\  landed"  cannot  occur 
before  the  event  “flight  X  taken  off").  Not  all  pairs  of  events  bear  this  relationship.  Causally 
unrelated  events  are  said  to  be  concurrent  and  can  occur  in  any  order  because  they  have 
no  effect  on  each  other.  The  temporal  ordering,  on  the  other  hand,  is  based  on  the  linear 
ordering  of  the  time  of  occurrence  of  the  events. 

The  time  of  occurrence  is  an  inherent  attribute  of  every  event.  Every  event  has  a  unique 
time  of  occurrence  or  time  stamp  associated  with  it,  which  is  assigned  at  the  commit  time 
of  the  action  that  causes  it.  A  time  stamp  is  in  fact  a  unique  identifier  of  an  event;  it 
implies  a  canonical  precedence  order  among  events.  It  repre.sents  the  registration  or  assertion 
time  of  an  event,  also  called  transaction  time  in  temporal  modeling  literature  [S.\85]  .  The 
granularity  with  which  the  time  of  occurrence  of  events  can  be  represented  is  application  and 
implementation  dependent.  UsuaUy  the  time  stamp  is  not  implemented  as  a  real  clock  value 
but  as  a  unique  serial  integer  for  reasons  of  simplicity.  However,  this  integer  value  can  easily 
be  mapped  into  a  real  clock  value  such  that  a  level  of  indirection  is  created.  .\s  far  as  the 
activation  of  the  behavior  is  concerned,  we  consider  that  the  time  of  detection  of  an  event  is 
the  same  as  its  time  of  occurrence.  This  may  not  be  true  for  actual  implemented  systems, 
but  it  is  not  a  problem  in  conceptual  modeling  as  long  as  the  order  is  preserved. 

Some  events  simply  signal  that  something  has  occurred  (e.g..  “machine  out  of  money", 
“engine  stopped"),  while  others  carry  information  in  the  form  of  event  attributes,  similar  to 
the  attributes  of  data  objects.  For  example,  in  the  event  “salaries  of  employees  working  on 
project  Alpha  have  been  updated”,  the  affected  employees’  names  and  salaries  (and  other 
attributes  of  employees)  are  conveyed  through  the  fired  rule  (or  rules)  as  attribute  values  of 
the  event. 

We  distinguish  events  that  occur  on  data  objects  or  attributes  stored  in  the  database 
(database  events)  from  those  events  that  are  external  to  the  database,  usually  generated 
by  application  programs  (external  events).  Figure  2.3  shows  a  third  classification  of  events 
(system  events),  which  are  signals  generated  by  the  underlying  system  such  as  interrupts  and 
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Ev&rr 


Figure  2.3:  Classification  of  Events 

clock  events^. 

A  database  event  is  the  result  of  a  database  operation  (insertion,  deletion,  modification, 
or  retrieval)  on  entities,  relationships,  or  their  attributes.  In  order  to  allow  more  flexibility 
in  the  specification  of  rules,  we  further  differentiate  an  attempted  operation  from  an  actually 
completed  operation.  This  is  done  by  specifying  an  event  immediately  before  it  occurs,  which 
enables  us  to  model  the  ability  to  reject  an  operation  before  actually  executing  it.  This  is 
essential  for  modeling  the  rejection  strategy  to  enforce  integrity  constraints  through  active 
behavior  at  the  conceptual  level.  At  the  logical  database  level,  an  attempted  operation 
translates  into  the  detection  of  the  event  at  the  time  of  its  occurrence.  The  operation  is 
suspended  until  the  condition  is  evaluated;  if  the  condition  is  satisfied,  then  the  operation  that 
would  cause  the  event  is  rejected.  If  the  implemented  DBMS  does  not  have  this  capability,  the 
typical  solution  is  to  rollback  the  operation  or  the  entire  transaction  in  which  the  operation 
was  performed. 

^By  underlying  system  we  mean  the  operating  system  and  DBMS  environment  that  are  potential  sources 
of  system  events. 
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External  events  are  signals  from  the  application  domain  such  as  “engine  stopped”  and 
“reviewer  reminded”.  At  the  conceptual  level,  specification  of  any  kind  of  signzd  should 
be  possible;  the  conceptual-to-logical  translation  step,  either  manual  or  automatic,  should 
consider  the  implementation  issues  of  signal  detection. 

We  also  distinguish  a  special  type  of  event  called  temporal  event,  which  may  be  a  time- 
constrained  signal  from  an  application  (external  event)  or  may  be  related  to  some  time- 
stamped  data  object  or  attribute  (database  event)  or  may  be  a  clock  event  generated  by  the 
underlying  system  (system  event).  For  example,  “time-out”  may  be  the  result  of  finding  that 
an  expiration  date  stored  in  the  database  has  been  exceeded  or  simply  an  event  caused  by 
the  system  clock.  Other  examples  of  temporal  events  are  “every  weekday  at  5:00  PM”,  “one 
month  after  the  occurrence  of  event  E”. 

We  specify  an  event  using  the  syntax  presented  in  figure  2.4,  in  which  we  consider  only 
primitive  events  and  conjunction  of  primitive  events.  Some  research  is  being  done  on  other 
types  of  composition  of  events  in  active  DBMSs  [Mis91,  GJS92],  e.g.,  disjunction,  sequence, 
and  closure,  but  the  complexity  of  the  detection  of  composite  events  has  prevented  the  de¬ 
velopment  of  practical  implementations.  The  most  useful  type  of  composition,  disjunction  of 
many  events,  has  been  implemented  in  research  prototypes  (Postgres  [SJGP90]  and  Starburst 
[WF90]);  it  is  easily  modeled  in  our  approach  by  specifying  as  many  behavior  sentences  as  the 
number  of  primitive  events  in  the  disjunction,  each  firing  the  same  list  of  actions.  The  notion 
of  conjunction,  characterized  by  the  connective  “AND”  is  that  of  occurrence  of  events  with¬ 
out  any  specific  order;  simultaneous  occurrence  of  primitive  events  is  not  considered  because, 
by  assumption,  each  event  has  a  unique  time  of  occurrence  (and  associated  detection  b  •  the 
system),  i.e.,  if  two  events  occur  simultaneously,  either  they  are  the  same  event  or  one  event 
subsumes  the  other.  Since  we  are  looking  at  an  immediate  practical  use  of  the  approach, 
we  leave  the  incorporation  of  more  complex  composition  of  events  in  the  language  for  future 
extensions,  which  will  be  quite  straightforward  at  the  conceptual  level. 

In  this  definition,  eventJd  is  the  unique  identification  of  the  event.  An  obj.name  is  the 
name  of  an  entity  set,  a  relationship  set  or  a  role  of  an  entity  in  a  relationship  and  attr.name 
is  the  name  of  an  attribute  of  object.  Objects,  roles,  attributes,  and  values  are  specified  in 
the  underlying  language  for  specification  of  ER  schemas,  as  well  as  the  lexical  conventions  for 
“identifier” . 

Events  other  than  database.event  [externaLevent  and  system.event)  are  user-defined  sig¬ 
nals,  possibly  with  parameters,  i.e.,  event  attributes.  The  definition  of  a  signalis  implementa¬ 
tion  dependent;  for  external  events,  it  will  usually  consist  of  a  stored  procedure  invoked  from 
an  application  program  or  directly  by  the  user.  The  following  definition  syntax  is  assumed 
and  used  as  the  basis  for  signal  calls  in  the  event  and  action  specification; 


signaLdefinition  :;=  CREATE  SIGNAL  signaLname  [  ‘(’  formaLparmJist  ‘)’  ] 
formal.parmJist  ::=  identifier  value.set 

[  identifier  value.set  ]* 
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event 

eventJd 
eventJype 
database. event 


obj.name 

attr.name 

external.event 

system-event 

signal 

signaLname 

parmAist 


::=  [  BEFORE  ]  event.id  eventJype 

[  AND  [  BEFORE  ]  event.id  event.type  ]’ 
::=  identifier 

::=  database.event  |  external-event  |  system.event 
::=  [attr.name  OF]  obj.name  MODIFIED 
I  obj.name  INSERTED 

I  obj.name  DELETED 

I  [attr.name  OF]  obj.name  RETRIEVED 
::=  identifier 
::=  identifier 
;:=  signal 
::=  signal 

::=  signaLname  [  ‘(’  parm.list  ‘)’  ] 

::=  identifier 

:;=  value  [  value  ]* 


Figure  2.4:  Syntajc  for  Event  Specification 

where  value.set,  i.e.,  the  allowed  set  of  values  for  the  identifier,  is  specified  in  the  underlying 
ER  schema.  As  an  example,  a  timeout  mechanism  can  be  specified  as: 

CREATE  SIGNAL  timeout(deadljne  :  date), 

where  “deadline”  is  the  event  attribute  and  may  refer  to  an  object  attribute  or  a  variable 
of  type  “date”. 

Every  database.event  has  a  set  of  pre-defined  attributes  that  it  carries  to  the  rules  it 
fires.  The  event  attributes  correspond  to  the  attributes  of  the  affected  objects,  and  the 
notation  depends  on  the  type  of  operation  that  caused  the  event.  The  event  attributes  may 
be  referenced  in  the  body  of  the  fired  rule,  i.e.,  in  the  specification  of  conditions  and  actions. 

For  an  entity,  all  its  attributes  are  carried  by  the  event,  and  the  following  notation  is  used, 
where  attr.name  is  the  name  of  the  attribute  as  specified  in  the  ER  schema: 


Type  of  database.event 

Predefined  attributes 

INSERTED 

NEW  attr.name 

DELETED 

OLD  attr.name 

MODIFIED 

NEW  attr.name,  OLD  attr.name 

RETRIEVED 

attr.name 

For  a  relationship,  besides  its  own  attributes,  if  any,  the  “NEW”  and/or  “OLD”  attributes 
of  the  participating  objects  are  inherited  by  the  relationship  and  also  carried  by  the  event. 
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2.1.2  Rules 

We  have  defined  a  rule  as  the  language  construct: 


rule 

::=  rule-id  [‘(’  description  *)’]  {  "[’  priority -level  ‘]’  ] 

[IF  condition  THEN]  action-list 

rule-id 

::=  identifier 

description 

::=  string 

priority-level 

;:=  identifier 

Like  event Jd,  rule.id  is  an  “identifier”,  which  provides  unique  identification  of  the  rule; 
description  is  an  optional  text  that  meaningfully  describes  the  rule  for  documentation  purpose; 
and  priority-level  is  an  optional  identification  of  the  priority  of  the  rule  according  to  a  user-de¬ 
fined  priority  policy.  In  general,  a  priority  policy  defines  a  number  of  priority  levels:  rules  with 
different  priority  levels  are  executed  in  the  precedence  order  of  the  levels;  and  rules  within 
the  same  priority  level  are  executed  in  some  order  dictated  by  the  rule  selection  strategy  of 
the  active  DBMS.  The  lower  level  of  priority  is  the  default,  and  the  simplest  priority  policy 
is  “no  policy”,  where  all  rules  have  the  same  priority  level,  and  the  order  of  execution  of  a 
set  of  fired  rules  is  left  to  the  active  DBMS. 

A  condition  is  a  predicate  over  the  state  of  the  database.  Its  specification  in  a  rule  is 
optional.  A  rule  without  a  condition  means  that  the  corresponding  actions  in  actionJist  are 
to  be  unconditionally  performed  whenever  the  associated  event  occurs  (is  detected).  We  use  a 
simple  syntax  for  condition  so  that  more  complex,  implementation  dependent  constructs  will 
need  to  be  defined  to  completely  specify  the  language.  Any  computable  database  predicate 
in  the  implementation  data  model  may  be  used  as  the  condition  part  of  a  rule.  In  general, 
a  predicate  may  comprise  a  collection  of  single  predicates  connected  by  “AND”  and  “OR”, 
possibly  negated  (“NOT”)  or  quantified  by  existential  quantifiers,  and  involving  aggregate 
constructs  such  as  “AVERAGE”,  “SUM”,  and  “COUNT”.  At  the  minimum,  a  predicate 
must  be  a  single  comparison  statement  between  an  attribute  and  a  value  in  the  attribute 
value  set  or  between  an  attribute  and  another  attribute.  We  follow  the  syntax  in  figure  2.5, 
where  NOT,  AND,  OR  and  IN  SET.OF  connectors  are  used. 

Like  objects  and  attributes,  a  value  is  specified  in  the  underlying  ER  schema  language, 
while  rel-operator  depends  on  the  predicates  supported  by  the  implementation  model  (the 
usual  relational  operators  are  =,  >,  >,  <,  <, 

A  condition  acts  as  a  guard  on  action.list.  If  the  condition  falls,  no  action  will  be  triggered 
and  the  rule  execution  will  fail.  For  a  given  rule,  the  same  condition  guards  all  actions  in  the 
associated  action-list. 

An  action-list  is  a  sequence  of  commands  that  can  be  database  actions,  i.e.,  operations 
to  be  performed  on  data  objects  and  their  attributes,  or  external  (user  defined)  actions 
such  as  raising  an  external  event  or  sending  a  message.  A  special  type  of  action,  “RE¬ 
JECT-OPERATION”,  is  defined  to  specify  rules  to  prohibit  certain  operations,  possibly  re¬ 
quiring  the  rollback  of  the  transaction  that  caused  the  firing  event.  Another  special  type  of 
action,  PROPAGATE.OPERATION,  allows  the  specification  of  a  cascaded  propagation  of 
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condition  predicateJist 

I  [  NOT  ]  predicateJist 

predicateJist  :;=  predicate  [  {AND  j  OR}  predicate  ]* 

predicate  ::=  [  NEW  |  OLD  ]  attr.name  [OF  obj.name] 

reLoperator  value 

I  [  NEW  I  OLD  ]  attr.name  [OF  obj.name] 

reLoperator  [  NEW  |  OLD  ]  attr.name  [OF  obj.name] 
I  [  NEW  I  OLD  ]  attr.name  [OF  obj.name] 

[NOT]  IN  SET.OF  ‘(’  attr.name  [OF  obj.name]  ‘)’ 


Figure  2.5:  Syntax  for  Condition  Specification 


the  effect  of  the  event  up  to  the  adjacent  objects;  for  example,  if  an  entity  is  deleted,  the 
deletion  is  propagated  to  the  relationships  which  the  deleted  entity  participates  in  and  to  the 
entities  that  are  associated  to  the  deleted  entity  by  “Is-A”  and  “ID”  connections.  The  syntax 
for  action  is  shown  in  figure  2.6. 

As  mentioned  before,  the  syntax  for  objects  and  attributes  is  defined  in  the  underlying 
ER  schema,  and  the  definition  of  predicate  is  given  in  the  syntax  for  condition.  The  lexical 
conventions  for  “string”  are  also  defined  in  the  grammar  of  the  ER  schema  specification 
language. 

Note  that  “RAISE”  is  an  action  that  applies  to  any  kind  of  events  that  are  raised 
by  the  execution  of  the  rule.  For  a  database.action,  a  raised  event  is  implicit,  so  we  do 
not  need  to  specify  the  fact  that  a  database.event  is  to  be  raised.  For  instance,  the  ac¬ 
tion  “DELETE.RELATIONSHIP  Works  BETWEEN  EMPLOYEE(ssn= “123456789”)  AND 
PROJECT”,  which  deletes  all  occurrences  of  that  employee  in  the  relationship  Works,  implic¬ 
itly  raises  the  database.event  “Works  DELETED”.  On  the  other  hand,  non-database  events 
such  as  “Intermediate-Checkpoint”  must  be  explicitly  raised  by  the  rule,  in  the  form  of  a 
“RAISE”  statement.  For  an  action  of  the  type  “MESSAGE”,  no  event  is  raised  unless  ex- 
plicit.iv  specified.  For  example,  we  may  want  to  raise  a  specific  event  “Candidate-Informed” 
as  a  consequence  of  the  action  “MESSAGE  :  ‘Inform  the  candidate  that  his/her  application 
has  been  denied’  ”. 

In  section  2.2  we  examine  the  semantics  of  the  language  constructs  we  propose,  based  on 
a  semi-formal  operational  approach. 

2.2  Semantics  of  the  Behavior  Specification  Language 

The  general  semantics  of  an  active  database  behavior.sentence  is  straightforward  and  has  the 
following  format: 
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actionJist  ::=  action  action]’ 
action  ;;=  database. action 
I  extemaLaction 
1  REJECT.OPERATION 
1  PROPAGATE.OPERATION  ‘(’  db.evenUist  ‘)’ 
database.action  ;;=  db.action\' event-id')' 

db.action  :;=  INSERT-ENTITY  obj.name  ‘(’  valueJist  *)’ 

I  INSERT -RELATIONSHIP  obj.name  [‘(’  value.iist  ‘)’] 

BETWEEN  rel.obj.list 

I  DELETE-ENTITY  obj.name predicate 
1  DELETE-RELATIONSHIP  obj.name  ‘(’  predicate  *)’ 

1  DELETE-RELATIONSHIP  obj.name  [‘(’  predicate  *)’] 

BETWEEN  reLobj.list 

I  MODIFY  obj.name  ‘(’  predicate  ‘)’  SET  ‘(’  value.iist ')’ 
valueJist  ::=  assignment  assignment]’ 
assignment  ;:=  attr.name  [OF  obj.name]  ‘=’  value 
reLobj.list  ;:=  rel.obj.pred  [AND  reLobj.pred]’ 
reLobj-pred  obj.name  [‘(’  attr.name  ‘=’  value  ‘j’] 

extemaLaction  ::=  RAISE  event.id  signaLname 

[  ‘(’  actuaLparm.list  ‘)’  ] 

I  MESSAGE  msg  [  ‘(’  event.id  signaLname 
[  ‘(’  actuaLparm.list  ‘)’  ]  ‘)’  ] 
actuaLparm.li$t  value  [  value  ] 

msg  string 

db.event.list  ::=  event.id  database.event  [‘,’  event.id  database.event]’ 


Figure  2.6:  Syntajc  for  Action  Specification 


Pre-conditions  : 

1.  event  is  detected.  If  “BEFORE”  is  specified  in  event,  then  the  event  was  detected  but 
has  not  actually  occurred. 

2.  condition  is  true. 

Execution  : 

The  actions  in  actionJist  are  executed. 

Post- conditions  : 


The  events  resulting  from  the  execution  of  actionJist  are  raised. 


Therefore,  the  semantics  of  the  active  database  behavior  specification  language  are  de¬ 
rived  from  the  operational  semantics  of  the  actions  in  actionJist  of  the  rules.  Since  actions 
are  the  constructs  of  the  language  that  produce  effects  on  the  state  of  the  database,  event 
and  condition  are  treated  as  pre-conditions  for  the  purpose  of  examining  the  semantics  of  a 
behavior. sentence. 

2.2.1  Formal  Specification  of  the  (ER)^  Model 

In  order  to  derive  an  operational  semantics  for  the  language,  i.e.  the  semantics  of  the  language 
in  terms  of  the  execution  of  its  operations  in  an  abstract  computing  machine,  we  need  to 
specify  the  (ER)^  model  in  a  formal  way.  We  will  use  the  following  notation  for  the  model 
constructs; 

•  /4  ;  set  of  attribute  names. 

•  V  :  set  of  attribute  domains  (value  sets). 

•  O  :  set  of  names  of  entity  types  and  relationship  types. 

•  £  ;  set  of  event  identifiers. 

•  D  ;  set  of  all  possible  database  events,  a  database  event  being  the  name  of  an  object 
type  in  0,  Mowed  by  the  occurred  event  (INSERTED,  DELETED,  MODIFIED,  RE¬ 
TRIEVED).  In  the  case  of  MODIFIED,  the  event  may  also  be  preceded  by  the  name 
of  an  attribute  in  A  and  the  keyword  OF. 

•  5  :  set  of  signal  names. 

•  R  :  set  of  rule  identifiers. 

•  P  :  set  of  identifiers  of  rule  priority  levels. 

Let  domain  :  A  — ►  V  be  a  function  that  maps  attribute  names  to  value  sets. 

Let  event.name  :  E  — ►  D  U  5  be  a  function  that  maps  event  identifiers  into  database 
events  or  signal  names. 

An  entity  type  descriptor  is  a  7-tuple: 

{ent.name,  entMttr.set,  ent^key.aitr.,  ent.notnulLattr, 

id.conn,  isa.conn,ent.insi) 

where 

•  ent.name  6  0  is  the  name  of  the  entity  type; 
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•  ent.attT.set  C  A  is  the  set  of  attributes  of  the  entity  type; 

•  ei  .key.attr  C  ent.attr .set  is  the  set  of  key  attributes  of  the  entity  type; 

•  ent.notnull.attr  C  ent.attr.set  is  the  set  of  attributes  that  are  not  allowed  to  have 
NULL  values; 

•  id.conn  is  a  pair  of  sets  {from. set,  to. set)  where  from.set  C  0  is  the  (possibly  empty) 
set  of  names  of  entity  types  th?t  are  ID-dependent  on  ent.name,  and  to.sei  C  O  is  the 
(possibly  empty)  set  of  names  of  entity  types  that  are  identifying  owners  of  ent.name-, 

•  isa.conn  is  a  pair  of  sets  {fromjset,to.set)  where  from.set  C  O  is  the  (possibly  empty) 
set  of  names  of  entity  types  that  are  subclasses  of  ent.name,  and  to.set  c  O  is  the 
(possibly  empty)  set  of  names  of  entity  types  that  are  superclasses  of  ent.name-, 

•  ent.inst  is  the  set  of  all  instances  that  belong  to  the  entity  type  in  a  given  database 
state.  Each  instance  represents  one  entity  and  consists  of  a  vzdue  for  each  attribute  in 
ent.attr.set  (some  of  which  may  be  NULL)  plus  a  value  for  a  surrogate-key  attribute. 

It  is  required  that  every  entity  instance  and  every  relationship  instance  have  a  unique, 
system-generated  surrogate-key  attribute  so  that  sets  of  surrogate- key  values  of  any  two  object 
types  are  disjoint.  It  is  also  required  that  the  values  of  attributes  in  ent.key.attr  be  not  NULL. 

A  relationship  type  descriptor  is  a  5-tuple: 

{rel.name,  rel.attr.set,  rel.obj.set,  rel.notnulLattr,  relJnst) 


where 

•  rel.name  €  0  is  the  name  of  the  relationsh’  j  type; 

•  rel.attr.set  C  A  is  the  (possibly  empty)  set  of  attributes  of  the  relationship  type; 

•  rel.obj.set  is  a  set  of  triples  (obj .name,  part,  card)  where  each  obj.name  6  O  is  the 
name  of  the  related  object  type;  part  G  {“Total”,  “Partial”}  is  the  participation  con¬ 
straint  of  obj.name  in  rel.name-,  and  card  G  {“1”,“M”}  is  the  cardinality  constraint  of 
obj.name  in  rel.name-, 

•  rel.notnull.attr  C  rel.attr.set  is  the  (possibly  empty)  set  of  attributes  that  are  not 
allowed  to  have  NULL  values; 

■  •  rel.inst  is  the  set  of  all  instances  that  belong  to  the  relationship  type  in  a  given  database 

state.  Each  instance  represents  "  e  relationship  and  consists  of  a  value  for  each  attribute 
in  rel.attr.set  plus  a  surrogate-key  value  for  each  entity  type  participating  in  the  re¬ 
lationship.  If  the  relationship  involves  other  relationships,  the  list  of  surrogate-key 
attributes  of  the  participating  relationships  becomes  part  of  the  instance  as  well. 


16 


An  event  type  descriptor  is  a  4- tuple: 


{event.id,  event  jittr. set,  eventspec,  f  ired-ruleset) 

where 

•  event.id  €  E  \s  the  identification  of  the  event  type; 

•  event. attr. set  C  A  is  the  (possibly  empty)  set  of  attributes  carried  by  the  event  type; 

•  event.spec  comprises  either  a  database  event  in  D  or  the  name  of  the  signal  (external 
or  system  event)  in  5; 

•  fiTed.rule.set  C  R  is  the  (possibly  empty)  set  of  rules  fired  by  the  occurrence  of  the 
event  type. 

A  rule  type  descriptor  is  a  7- tuple: 

(rule.id,  rule  jittr. set,  priority. level,  firing  jevent, 
condition. spec,  action  Jist.spec,  raisedjevent.sei) 

where 

•  rule.id  €  ft  is  the  identification  of  the  rule  type; 

•  rule.attr.set  C  A  is  the  (possibly  empty)  set  of  attributes  of  the  rule  type  (carried  by 
its  firing  event); 

•  priority. level  €  P  is  the  identification  of  the  priority  level  of  the  rule  type,  if  any; 

•  firing. event. set  C  E  is  the  (at  least  singleton)  set  of  event  types  that  fire  the  rule; 

•  condition. spec  is  the  specification  of  the  condition  p«irt  of  the  rule  in  the  active  behavior 
specification  language; 

•  action.list.spec  is  the  specification  of  the  actions  of  the  rule  in  the  active  behavior 
specification  language; 

•  raised.event.set  is  the  (possibly  empty)  set  of  event  types  raised  by  the  execution  of 
the  rule. 

A  general  constraint  of  the  model  is  that  names  in  0  and  5  and  identifiers  in  E  and  R 
be  unique  throughout  the  database,  as  well  as  names  of  attributes  within  (ER)^  object  type 
descriptors. 

An  (ER)2  schema  is  a  4-tuple  (ENTITY,  RELATIONSHIP,  EVENT,  RULE)  where  EN¬ 
TITY  is  a  set  of  entity  type  descriptors,  RELATIONSHIP  is  a  set  of  relationship  type  descrip¬ 
tors,  EVENT  is  a  set  of  event  type  descriptors,  and  RULE  is  a  set  of  rule  type  descriptors. 
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2.2.2  Operational  Semantics  of  Actions 

As  presented  in  section  2.1,  the  following  actions  are  specified  as  part  of  the  action.list. 

•  RAISE  event.id  signaLname  [  ‘‘('actuaLparm.listy  ] 

•  MESSAGE  msg  [  ‘(’euenLid  signaLname  [  actuaLparm.lisfy  ]‘)’  ] 

•  REJECT.OPERATION 

•  PROPAGATE-OPERATION  T  db.eventJisty 

•  database  actions:  INSERT.ENTITY,  INSERT-RELATIONSHIP,  DELETE-ENTITY, 
DELETE-RELATIONSHIP,  and  MODIFY. 

The  operational  semantics  of  each  action  is  defined  below  in  the  form  of  pre-conditions, 
execution,  and  post-conditions.  This  semantics  is  nested  in  the  semantics  of  the  behav- 
ior.sentence  in  which  the  action  appears,  i.e.,  the  latter  will  be,  in  general,  defined  as: 


Pre-conditions  (firing  event  detected,  condition  true) 
Execution  : 

pre-conditions,  execution,  post-coiiditions  for  action  1. 
pre-conditions,  execution,  post-conditions  for  action  2. 

pre-conditions,  execution,  post-conditions  for  action  N. 
Post-conditions  (resulting  events  raised) 


It  is  assumed  that  the  underlying  active  DBMS  in  which  the  actions  are  executed  has 
the  capabilities  for  suspending,  aborting,  and  rolling  back  database  operations  (or  the  en¬ 
tire  transaction  in  which  the  operation  is  performed),  as  well  as  an  adequate  data  struc¬ 
ture  (a  list)  for  keeping  track  of  the  detected  events.  The  interesting  actions  are  the  exter¬ 
nal  actions  (“RAISE”  and  “MESSAGE”)  and  the  special  types  of  database  actions  (“RE¬ 
JECT-OPERATION”  and  “PROPAGATE-OPERATION”)  introduced  in  the  (ER)^  model. 
The  primitive  database  actions  have  been  well  defined  in  the  context  of  manipuAtion  lan¬ 
guages  for  extended  ER  models  (AH85,  CERE88]  and  transaction  specification  languages  for 
semantic  data  models  [NB91].  Their  operational  semantics  is  based  on  the  relational  imple¬ 
mentation  of  the  ER  schema,  i.e.,  it  is  based  on  the  operational  semantics  of  the  DBMS’s 
DDL/DML,  which  we  do  not  discuss  in  this  report. 

RAISE  e  :  s{pj) 

Given  evenLid  e,  signaLname  s,  and  actuaLparm.list  pj,  RAISE  adds  e  to  the 
list  of  detected  events;  s  and  the  values  in  pJ  must  conform  to  the  event  type 
descriptor  of  e. 

Pre-conditions: 
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1.  e  €  £ 

2.  s  e  S,  event.name{e)  =  s 

3.  If  pJ  is  specified,  let  pj  =<  aj,a2."-,fln  > 

and  evenLattr.set  of  e  ~<  Ai,  A2,  •••,  >.  Then  each  value  must  be  in  the 

proper  domain,  i.e.: 

a,  €  domain{A,),  1  <  i  <  n 

Execution; 

Add  e  to  the  list  of  detected  events. 

Post-conditions: 
e  is  raised. 


MESSAGE  :  m(c  :  s{pj)) 

Given  msg  m,  eventjd  e,  signal-name  s,  and  actuaLparm.list  pJ,  MESSAGE 
outputs  m,  typically  a  string  of  characters.  If  e  ;  s{pj)  is  specified,  it  behaves 
exactly  like  in  RAISE  e  ;  s{pj). 

Pre-conditions: 

If  e  :  s{pj)  is  specified,  same  as  1.,  2.,  3.  for  RAISE  c  ;  ${pJ). 

Otherwise  no  pre-condition. 

Execution  ; 

Output  m.  If  e  :  s{pJ)  is  specified,  add  e  to  the  list  of  detected  events. 
Post-conditions  : 

If  e  :  s{pj)  is  specified,  then  e  is  raised. 

Otherwise  no  post-condition. 


REJECT-OPERATION 

If  “BEFORE”  was  specified  with  the  firing  event,  then  the  suspended  operation 
that  would  cause  the  event  is  aborted;  otherwise,  the  operation  is  rolled  back. 

Pre-conditions: 

None 

Execution; 
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If  “BEFORE”  wa5  specified,  then  abort  the  suspended  operation.  Otherwise,  roll 
back  the  operation  that  caused  the  event. 

Post-conditions: 

If  “BEFORE”  was  specified,  no  post-condition. 

Otherwise  the  firing  event  is  raised. 


PROPAGATE.OPERATION  (eJ) 

Selectively  propagates  the  operation  that  caused  the  firing  event  to  the  adjacent 
objects  listed  in  (eJ). 

Pre-conditions: 

1.  Let  eJ  =<  e\  :  di,e2  :  d2,---,en  ■  dn  >-  Then  each  event-id  must  be  a 
valid  event  identifier,  i.e.; 

Ci  6  E,  1  <  i  <  n 

2.  Each  database-event  di  must  be  a  valid  database  event,  i.e.: 
di€  D,l<i<n 

3.  Each  database  event  must  correspond  to  its  event  identifier  in  the  event  type 
descriptor,  i.e.: 

di  =  event. name{ei),  1  <  j  <  n 

4.  Let  0/  be  the  name  of  the  object  in  the  firing  event, 

and  o,,  1  <  i  <  n  the  name  of  the  object  in  the  database  event  d,.  Then 

•  If  Of  is  an  entity  type,  then  each  Oj  must  be  either  an  entity  type  con¬ 
nected  to/from  Of  by  an  “ID”  or  “Is_A”  arc,  or  a  relationship  type  which 
Of  participates  on,  i.e.: 

0,-  €  {id. conn,  from  set  U  idjconn.toset  U  isa. conn,  from  set  U 

isa-conn.toset  U  rel-connset). 

•  If  0/  is  a  relationship  type,  then  each  o,  must  be  an  object  type  (entity 
or  relationship)  that  participates  in  o/,  i.e.: 

o.i  =  rel.obj set. obj -name  for  some  obj.name  described  in  the 
reljobjset  of  oy. 

Execution  : 

Le'  o-e  be  the  name  of  the  occurred  update  operation  in  the  firing  event  (i.e.,  the 
occurred  event  on  o/).  Then  the  execution  semantics  of  each  propagation  follows 
the  semantics  of  the  corresponding  individual  operation,  i.e.: 

•  If  o.e  =  “INSERTED”  then  execute  insert  operation  on  (entity  or  relation¬ 
ship)  Oi,  1  <  i  <  n. 
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•  If  o.e  =  “DELETED”  then  execute  delete  operation  on  (entity  or  relation¬ 
ship)  o,,  1  <  t  <  n. 

•  If  o.e  =  “MODIFY”  then  execute  modify  operation  on  (entity  or  relationship) 
o,,  1  <  t  <  n. 

Post-conditions; 

The  post-conditions  of  the  individual  propagated  operations  hold. 


2.3  (ER)^  Diagrams 

The  conceptual  schema  in  the  (ER)^  model  comprises  the  usual  ER  schema  plus  the  specifica¬ 
tion  of  active  behavior  in  the  form  of  events  and  rules.  For  the  conceptual-to-logical  mapping 
step  of  the  database  design  process,  a  textual  specification  of  the  combined  schema  in  the 
appropriate  language  is  adl  that  the  translation  tools  need  in  order  to  be  able  to  generate  the 
database  structure  and  behavior  definition  statements  in  the  target  DBMS. 

The  diagrammatic  representation  extensively  used  during  the  conceptual  design  phase  is 
a  graphical  tool  that  helps  the  database  designer  in  three  aspects: 

•  Communication  with  the  users. 

•  Automatic  generation  of  the  textual  specification  from  the  graphical  representation. 

•  Documentation  of  the  design. 

We  extend  these  facilities  supplied  by  the  ER  diagram  with  a  graphical  notation  for  events 
and  rules,  to  provide  the  database  designer  with  a  means  of  representing  active  database 
behavior  along  with  the  structural  data  constructs. 

In  an  (ER)^  diagram,  an  event  is  represented  as  a  circle  and  a  rule  as  a  parallelogram. 
Directed  edges  represent  connections  between  events  and  rules  and  between  events  and  data 
objects  (entities  and  relationships).  Figure  2.7  shows  the  representation  of  a  single  behavior 
in  terms  ot  the  firing  event,  the  rule,  and  the  events  raised.  The  connections  between  events 
and  rules,  and  between  events  and  the  outside  objects  are  also  explicitly  shown.  In  an  actual 
diagram,  there  is  no  need  to  label  “Fires”  and  “Raises”  arcs;  the  connections  between  events 
and  rules  are  implicit;  an  event  “fires”  rules  and  a  rule  “raises”  events.  The  connections 
“Affects”  and  “Affected.by”  are  labeled  in  an  (ER)^  diagram  with  the  type  of  database  event 
(modification,  insertion,  deletion,  or  retrieval).  Non-database  events  (signals),  are  represented 
by  the  events  themselves,  i.e.,  they  are  not  connected  to  data  objects. 
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Figure  2.7:  Diagrammatic  Representation  of  an  Active  Behavior 

2.3.1  Meta-schema 

As  we  did  with  the  ER  model,  we  can  specify  the  (ER)^  model  in  a  meta-schema  and  rep¬ 
resent  it  as  an  (ER)^  diagram,  i.e.  a  meta-(ER)^-diagram  of  the  (ER)^  model  itself.  This 
is  shown  in  figure  2.8,  where  the  event  and  rule  objects  are  integrated  in  the  model  with 
the  appropriate  notation,  and  the  “ER2-Connection”’s  of  figure  2.2  are  explicitly  represented 
by  the  links  “Affected.by”,  “Affects”,  “Fires”,  “Raises”,  and  by  the  relationships  “Precedes" 
and  “Priority”.  The  external  environment  (system,  applications,  and  users)  is  also  shown  as 
a  potential  source  and  target  of  events. 

This  meta-schema  is  part  of  the  meta-database  that  stores  meta-data  about  the  design 
process,  i.e.,  the  definition  of  schemas  at  different  levels  and  their  mappings.  The  meta¬ 
database  is  a  self-documentation  of  the  design  process,  and  is  an  essential  source  of  information 
for  further  extensions  to  the  database  design  methodology. 

2.3.2  Example 

As  an  illustration,  figure  2.9  shows  an  (ER)^  diagram  of  a  company’s  EMPLOYEE- 
DEPARTMENT-PROJECT  database  with  some  events  and  rules  attached  to  the  data  ob¬ 
jects.  The  following  ER  schema  is  assumed  -  for  simplicity,  details  such  as  cardinality  ratios 
(“1”,“M”),  identification  dependencies  (“ID”),  participation  constraints  (“Total”),  and  roles 
(“manager”,  “employer”)  are  shown  only  in  the  diagram,  and  attributes  are  specified  only  in 
the  textual  schema: 

•  EMPLOYEEfssn.  name,  job,  address,  birth-date,  status,  salary) 

•  DEPARTMENTfname.  location) 

•  PROJECTfname.  budget) 
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Figure  2.8:  Meta-(ER)^-diagram  of  the  (ER)^  Model 

•  DEPENDENT(EMPLOYEE-Ssn.  name,  birth-date) 

•  EmnlovedfEMPLOYEE-ssn.  DEPARTMENT-namel 

•  ManagesfEMPLOYEE-ssn.  DEPARTMENT-namel 

•  Works(EMPLOYEE-Ssn.  PROJECT-name.  start.date,  hours-week) 

The  following  behavioral  sentences  are  specified  in  terms  of  the  events  and  rules  repre¬ 
sented  in  figure  2.9: 

WHEN  el  :  PROJECT  MODIFIED 
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Figure  2.9:  (ER)^  Diagram  of  a  COMPANY  Database 


FIRE  rl  (“Policy  for  budget  reduction”)  : 

IF  NEW  budget  <  OLD  budget 

THEN  DELETE_ENTITY  EMPLOYEE  (ssn  =  OLD  EMPLOYEE_ssn, 
status  =  “temporary”)  (e2), 

RAISE  e3  :  salary  .review. 

WHEN  e2  :  EMPLOYEE  DELETED 
FIRE  r2  (“Restriction  to  firing  engineers”)  : 

IF  OLD  job  =  “engineer” 

THEN  MESSAGE  :  “Employee  is  an  engineer,  deletion  rejected”, 
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REJECT.OPERATION. 


WHEN  e2  ;  EMPLOYEE  DELETED 

FIRE  r3  (“Cascaded  deletion  of  temporary  employees”)  ; 

IF  OLD  status  =  “temporary” 

THEN  PROPAGATE-OPERATION  (  e4  :  Employed  DELETED, 
e5  :  Works  DELETED,  e6  :  DEPENDENT  DELETED). 

WHEN  e5  :  Works  DELETED 

FIRE  r4  (“Warning  message  to  project  manager”)  : 

MESSAGE  :  “Inform  change  on  employee  assignment  to  project  manager” 
(e7  :  manager-warning). 


The  (ER)^  diagram  represents  the  active  database  behavior  in  the  form  of  events  and  rules 
and  their  interaction  with  data  objects.  To  avoid  cluttering  the  diagrammatic  representation, 
we  chose  to  keep  the  specification  of  events,  conditions,  and  actions  apart  from  the  diagram, 
using  textual  description.  The  same  user  interface  design  technique  is  adopted  by  most  of 
the  current  ER  diagramming  tools,  where  the  attributes  are  specified  in  pop-up  windows  that 
are  displayed  when  the  corresponding  object  symbols  are  clicked.  This  technique  keeps  the 
diagram  simple  and  easy  to  read,  without  loss  of  information.  In  addition,  the  use  of  different 
Une  styles  and  colors  for  structural  and  behavioral  constructs  would  help  making  the  diagram 
more  readable. 

As  shown  in  the  above  example,  the  (ER)^  model  can  capture  a  variety  of  constraints  and 
situation/action  behaviors,  such  as  a  high-level  organizational  policy  (rule  rl),  a  restrictive 
prescription  (rule  r2),  the  enforcement  of  an  integrity  constraint  (rule  r3),  or  a  databa.se  event 
aderter  (rule  r4).  Potentially,  this  framework  can  represent  any  application-relevant  behavior 
that  can  be  managed  by  an  active  DBMS.  In  addition,  this  representation  can  be  ea.sily 
adapted  to  data  abstraction  extensions  to  the  ER  model  such  as  generalization/specialization 
and  aggregation.  As  pointed  out  before,  those  extensions  do  not  disturb  the  (ER)^  framework 
because  of  the  orthogonality  of  the  added  dimension. 


2.4  Mapping  of  (ER)^  Specification  into  DBMS  Constructs 

2.4.1  Meta-database  of  the  Schema  lYanslation 

During  the  traditional  schema  translation  process  from  conceptual  to  logical  level,  the  transla¬ 
tion  tools  acquire  knowledge  about  the  conceptual  schema  from  the  input  file,  apply  the  map¬ 
ping  procedures,  and  generate  the  logical  schema  in  the  target  DBMS.  This  meta-information 
about  the  schemas  and  their  mapping  is  a  valuable  resource  that  must  be  stored  in  a  meta¬ 
database  for  further  use. 

The  most  visible  use  of  the  meta-database  is  for  self-documentation  of  the  design  and 
possible  use  as  a  basis  for  schema  evolution  management  [MR90].  In  a  full  fledged  CASE 
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environment,  the  meta-database  can  be  combined  with  additional  meta-information  about 
the  process  design  to  form  a  project  database. 

The  meta-database  is  also  useful  for  extensions  to  the  query  capability  of  the  database 
system.  For  instance,  graphical  languages  for  querying  the  conceptual  schema  are  more  con¬ 
cise  and  adequate  for  naive  database  users  than  the  query  languages  provided  by  the  DBMS, 
e.g.,  SQL.  The  information  stored  in  the  meta-database  is  fundamental  for  the  translation 
of  queries  in  the  conceptual  schema  to  actual  queries  in  the  DBMS  language.  This  idea  can 
be  extended  to  querying  multiple,  heterogeneous  database  systems,  in  which  various  meta¬ 
databases  would  be  integrated  for  assisting  the  different  conceptual-to-logical  query  trans¬ 
formations.  Some  highly  specialized  database  applications,  such  as  scientific  applications, 
may  require  a  specific  query  language  that  must  also  use  the  meta-database  for  translation 
[MLM+92]. 

In  our  work,  we  use  the  meta-database  as  the  central  repository  of  schema  design  infor¬ 
mation  to  incorporate  active  behavior  translation  in  the  database  design  process.  Figure  2.10 
shows  the  types  of  meta-information  needed  for  this  purpose: 


Figure  2.10:  Meta-database:  ER  schema,  Relational  schema,  and  their  Mapping 

(LBL  tool  set) 

•  ER  objects  (Entity  sets  and  Relationship  sets)  and  their  mapping  into  relation  schemas. 
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•  ER  object  connections  (arcs  in  the  ER  diagram)  and  their  mapping  into  referential 
ir*9grity  constructs  supported  by  the  DBMS. 

•  Object  attributes  and  their  mapping  into  relational  attributes,  along  with  information 
about  key  attributes. 

•  Value  sets  and  their  mapping  into  the  domains  supported  by  the  target  DBMS.  Usually 
schema  translation  tools  are  implemented  in  such  a  way  that  the  value  sets  of  attributes 
in  the  ER  schema  are  tailored  to  the  domains  in  the  target  DBMS;  hence,  the  value 
set-to-domain  mapping  is  a  one-to-one  mapping.  When  the  tools  support  more  than  one 
target  DBMS,  different  value  set  options  are  available  for  the  specification  of  attributes. 

2.4.2  Active  DBMS  Language  Constructs 

Although  a  standardization  effort  is  being  done  in  the  area  of  data  definition  and  manipulation 
languages,  there  are  significant  differences  between  the  various  commercial  DBMSs.  In  par¬ 
ticular,  the  syntax  of  the  active  database  constructs  varies  significantly.  Here  we  consider  the 
constructs  currently  present  in  commercial  relational  DBMSs;  they  reflect  the  development 
of  research  prototypes,  from  System  R  to  Starburst  and  Postgres. 

Three  types  of  active  database  constructs  have  been  implemented  as  part  of  the  data 
definition  language  of  relational  DBMSs:  triggers,  rules,  and  exception  handlers.  The  func¬ 
tionality  of  triggers  and  rules  is  similar  in  practice,  since  both  are  general  mechanisms  to 
specify  active  behavior  in  the  form  of  situation/action  rules,  database  triggers,  and  event 
alerters. 

Triggers  are  present  in  the  proposed  standards  SQL2  and  SQL3  [Mel90]  and  implemented 
in  Sybase  [SYB87],  Oracle  [Kos92],  and  Interbase  [INT90].  The  syntax  varies  from  product 
to  product;  the  following  is  the  proposed  syntax  in  SQL2/SQL3: 

CREATE  TRIGGER  trigger.name 
{  AFTER  I  BEFORE  } 

{  INSERT  I  DELETE  |  UPDATE  [OF  columnJist]  } 

ON  table.name 
[  REFERENCING 

{  OLD  [  AS  ]  correlation.name 

[  NEW  [  AS  ]  correlation.name  ]  }  1 
{  NEW  [  AS  ]  correlation^name 

[  OLD  [  AS  ]  correlation.name  ]  }  ] 

[  WHEN  search  condition  ] 

ti  i'jgered.SQL.stat€mentJist 
[  FOR  EACH  {  ROW  |  STATEMENT  }  ] 

where  trigger.name,  table.name  and  correlationjname  are  respectively  identifiers  for  the  trig¬ 
ger,  the  tables  involved  in  the  trigger,  and  the  correlated  tables  used  as  aliases  for  the  transi¬ 
tion  tables  containing  old  and  new  values  of  the  affected  tuples;  columnJist  is  a  list  of  attribute 
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identifiers;  and  search-condition  and  triggered^SQL-statementJist  are  predicates  and  opera¬ 
tions  specified  in  the  underlying  SQL  data  manipulation  language. 

Rules  are  the  basic  constructs  in  Ingres  [ING90]  and  RDB/VAX  [DEC89].  The  following  is 
the  syntax  in  the  Knowledge  Management  Extension  of  Ingres;  it  combines  rules  with  stored 
procedures. 

CREATE  RULE  mle.name 
AFTER 

{  INSERT  INTO  |  DELETE  FROM  | 

UPDATE  ON  I  UPDATE  column.name  OF  } 
table.name 

[  REFERENCING  [  OLD  AS  correlation.naTne  ] 

[  NEW  AS  correlation.name  ]  ] 

[  WHERE  qualification  ] 

EXECUTE  PROCEDURE  procedure.name  ‘(’  procedure. parameters  ')’ 


CREATE  PROCEDURE  procedure.name  ‘(’  parameter.list  ‘)’ 
AS  (  declare.section  ] 

BEGIN 

statement-list 

END 


Here  also  rule.name,  column.nam€,  table.name^  correlation.name^  and  procedure.name 
are  identifiers;  and  qualification  is  a  predicate  over  the  affected  tables.  A  procedure  is  a 
mechanism  with  the  full  power  of  a  database  programming  language  containing  parameters, 
a  declaresection  for  declaration  of  local  variables,  and  a  statement.list  that  includes  database 
operations,  control  statements  (IF,  WHILE,  RETURN),  assignment  statements,  MESSAGE 
and  RAISE  ERROR  statements. 

Although  it  lacks  many  desirable  features  such  as  detection  of  events  “after”  and  “be¬ 
fore”  they  occur,  priority  information,  retrieval  events,  and  arbitrary  procedures  as  events  to 
emulate  signals,  the  rule/ procedure  construct  of  Ingres  has  the  advantage  of  modularity.  Po¬ 
tentially,  this  approach  could  be  extended  to  incorporate  all  these  features  and  could  be  used 
in  any  SQL  extension  with  stored  procedures  and  rules  or  triggers,  such  as  in  SQL2/SQL3, 
Sybase,  and  Oracle.  In  the  following  mapping  algorithms,  we  use  this  construct  as  the  general 
language  construct  of  the  target  active  DBMS. 

The  last  type  of  construct  present  in  current  active  DBMSs  is  the  exception  handler,  a 
very  limited  mechanism  to  deal  with  signals.  The  general  construct  is  of  the  form: 

WHENEVER  SQLsignal  exception-action, 

where  SQL-signal  can  be  any  of  a  few  error  codes  originating  from  embedded  SQL  statements, 
and  exception-action  is  basically  a  message  or  a  jump /call  to  an  exception  handling  procedure 
written  in  the  host  language.  Although  the  functionality  is  present  for  a  restricted  set  of 


system  signals,  we  will  not  deal  with  this  mechanism  because  of  its  limitation  (the  SQL.signal 
basically  indicates  the  occurrence  of  an  error  in  the  execution  of  SQL  commands  embedded 
in  programs  written  in  a  host  language). 

2.4.3  Mapping  Process 

Recall  that  the  specification  of  active  behavior  in  the  (ER)^  model  is  a  list  of  behavior.sen- 
tences,  each  one  defined  as: 


behavior.sentence 

event 

rule 


WHEN  event  FIRE  rule 
event.id  eventJype 

rule.id  [‘(’  description  ‘)’]  [  ‘[’  priority.level  ‘]’  ] 
[IF  condition  THEN]  actionJist 


We  assume  the  following  syntax  for  rule  definition  in  the  target  DBMS,  which  is  more 
general  than  that  of  Ingres  ;  the  procedure  definition  is  the  same  as  in  Ingres: 

CREATE  RULE  rule.name  [  description  ]  [  priorityJevel  ] 

[ BEFORE  I  AFTER ] 

{  signaLname  ‘(’  signaLparameters  *)’  j 
{  INSERT  INTO  |  DELETE  FROM  | 

UPDATE  ON  I  UPDATE  column.name  OF  ) 

RETRIEVE  ON  |  RETRIEVE  column.name  OF  }  table.name  } 

EXECUTE  PROCEDURE  procedure.name  ‘(’  procedure.parameters  ‘)’ 

The  following  meta-database  look-up  functions  are  defined  for  assisting  the  mapping  pro¬ 
cess: 

get_obj-map(o6j-name)  returns  the  table  name  to  which  obj.name  was  mapped. 

get_attr_map( aftr.name)  returns  the  column  name  to  which  attr.name  was  mapped. 

get_conn(o6j_name)  returns  the  list  of  objects  connected  to  obj.name  in  the  ER  schema,  along 
with  the  type  of  each  connection. 

get_attr_list(o6j_name)  returns  the  list  of  attributes  of  obj.name. 

get_attr_list_map( ohj.name)  returns  the  list  of  column  names  to  which  the  list  of  attributes  of 
obj.name  was  mapped.  In  an  actual  implementation,  this  function  is  performed  through 
a  get_attrJist(o6j_name)  followed  by  a  sequence  of  get_attr_map(a<tr_namc). 

get_value-set_map(  ua/ue_set)  returns  the  domain  name  to  which  value.set  was  mapped. 

Not  surprisingly,  with  the  information  provided  by  the  meta-database  the  mapping  be¬ 
comes  straightforward.  The  mapping  process  proceeds  as  follows. 
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1.  Input;  a  list  of  behavioT. sentences. 

Each  behavior.sentence  generates  a  pair  (rule  definition,  procedure  definition),  as  de¬ 
scribed  below. 

2.  Each  obj.name  referred  in  the  event,  condition,  or  actionJist  parts  of  the  behav¬ 
ior.sentence  \s  mapped  into  a  table.name  using  get_obj_map( ohj.name). 

3.  Each  attr.name  is  mapped  into  a  coluTnn.name  using  get.attr_map(attr_name). 

4.  Each  value  referred  in  the  condition  or  actionJist  parts  of  the  behavior.sentence  is 
mapped  into  a  value  in  the  corresponding  domain  obtained  by  get.value_set_map 
{value.set). 

5.  Rule  definition: 

•  Output: 

CREATE  RULE  rule.id  [  description]  [  priority. level] 

{  BEFORE  I  AFTER  }  event 

EXECUTE  PROCEDURE  procedure.name  (  procedure.parameters  ); 

•  rule.id  maps  directly  into  rule.name  unless  corrections  are  needed  to  meet  naming 
conventions  for  identifiers. 

•  description  maps  into  a  string  of  characters  for  documentation  purpose. 

•  priority.level  maps  into  an  implementation-dependent  definition  of  priority  (e.g. 
an  integer  sequence  number). 

•  event  maps  into  the  corresponding  language  construct: 

-  Czise  database.event: 

*  attr.name  OF  obj.name  MODIFIED  — ►  UPDATE  column.name  OF  ta¬ 
ble.name 

*  obj.name  MODIFIED  — ►  UPDATE  ON  table.name 

*  obj.name  INSERTED  — ►  INSERT  INTO  table.name 

*  obj.name  DELETED  — >■  DELETE  FROM  table.name 

*  attr.name  OF  obj.name  RETRIEVED  — >■  RETRIEVE  column.name  OF 
table.name 

*  obj.name  RETRIEVED  — ►  RETRIEVE  ON  table.name 

-  Case  extemaLevent  or  system.event: 

*  The  translation  into  signaLname  [  (  signaLparameters  )  ]  will  depend  on 
the  implementation  of  signals. 

•  The  translation  of  procedure.name  (  procedure.parameters  )  will  depend  on  the 
procedure  definition,  as  explained  below. 

6.  Procedure  definition: 
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•  Output: 

CREATE  PROCEDURE  procedure  ^name  (  parameter  .list  ) 

AS  declare.section 
BEGIN 
statementJist 
END; 

•  procedure.name  is  mapped  into  proc.ru/e_id  to  associate  the  identification  of  the 
procedure  to  the  rule  that  calls  it. 

•  parameter.list  corresponds  to  the  attributes  of  event. 

-  Case  database.event  ;  the  parameters  are  the  predefined  event  attributes 
(see  the  table  at  the  end  of  section  2.1.1)  mapped  into  columnjnames  using 
get_attrjnap(ai/r_nar7ie).  Each  column.name  is  prefixed  by  “o_”  (for  old)  or 
“n.”  (for  new)  if  the  event  was  an  update  event,  and  followed  by  the  domain 
corresponding  to  the  value.set  of  attr.name.  For  example,  suppose  attribute 
“DEPARTMENTjiame”  of  object  “Employed”  with  value.set  “varchar”  is 
mapped  into  column  “dname”  of  relation  “EMPLOYEE”  with  domain  “var¬ 
char”;  then  if  the  event  is  “Employed  DELETED”,  the  corresponding  pro¬ 
cedure  parameter  will  be  “o.dname  varchar”;  if  the  event  is  “Employed  IN¬ 
SERTED”,  it  will  be  “n.dname  varchar”;  and  if  the  event  is  “Employed  MOD¬ 
IFIED”,  it  will  be  “o-dname  varchar,  n.dname  varchar”.  Also,  in  this  example, 
note  that  table.name  =  get. objjnap( “Employed”)  =  “EMPLOYEE”. 

-  Case  extemaLevent  or  system.eveni:  each  parameter  is  a  user-defined  pair 
“identifier  ;  value.sef  mapped  into  the  corresponding  “identifier  domain”  in 
parameterJist.  Every  identifier  maps  into  an  identical  name  unless  corrections 
are  needed  to  meet  naming  conventions  of  the  target  DBMS. 

-  In  any  case,  the  actual  procedure.parameters  in  the  EXECUTE  PROCE¬ 
DURE  statement  inside  the  rule  definition  will  be  a  list  of  pairs  “for- 
mal.parameter jiame  =  value”,  one  for  each  parameter  in  parameterJist.  A 
“formal.parameterjiame”  is  as  defined  above  and  “value”  is  either  the  col¬ 
umn-name  prefixed  by  the  qualification  keywords  “new.”  or  “old.”  for 
database  events  or  a  user-specified  value  mapped  into  the  corresponding  do¬ 
main  for  non-database  events.  For  example,  the  actual  parameter  corre¬ 
sponding  to  the  formal  parameter  “n.dname  varchar”  will  be  “n.dname  = 
new. dname”. 

•  The  declare.section  contains  declarations  of  variables  that  are  locally  referenced  by 
the  procedure.  The  foUowir'r  variables  will  be  used  in  the  definition  of  procedures 
invoked  by  rules: 

-  “message  string”  to  keep  the  text  of  msg  specified  with  the  action  “MESSAGE 
:  msg”. 

-  “counter  integer”  to  keep  the  number  of  tuples  in  a  table  that  is  used  for 
checking  the  existence  of  tuples  satisfying  some  condition. 
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•  The  statementJist  will  contain  the  statements  corresponding  to  the  condition  and 
actionJist  parts  of  the  rule. 

-  For  each  predicate  in  condition: 

*  Case  [  NEW  |  OLD  ]  attr.name  [OF  obj.name]  reLoperator  value 
— >  IF  [table.name].[n-  |  oJ\column.name  reLoperator  value 

where  reLoperator  and  value  are  mapped  into  the  corresponding  operator 
and  value  in  the  target  DBMS  language. 

*  [  NEW  1  OLD  ]  attr.namex  [OF  obj.namei]  reLoperator  [  NEW  |  OLD  ] 
attr.name2  [OF  obj.name2] 

— ►  IF  [table.namei].[n.  j  o_]co/umn_namei  reLoperator  [table.nam€2].[n-  \ 
o.]column.name2 

*  [  NEW  I  OLD  ]  attr.namei  [OF  obj.namei]  [NOT]  IN  SET.OF 
(  attr.name2  [OF  obj.name2]  ) 

— »  IF  [table.namei].[n-  |  o_]co/umn_namei  [  NOT  ]  IN  SELECT  col- 
umn.name2  FROM  table.name2  ) 

If  obj.namei  is  omitted,  then  table.namci  is  the  same  as  the  table.name 
corresponding  to  the  obj.name  in  the  firing  event. 

—  For  each  action  in  action.list: 

*  Case  INSERT.ENTITY  obj.name  (  value.list ) 

— ‘  INSERT  INTO  table.name  VALUES  {column.namei  =  valuci) 
for  1  <  i  <  n,  assuming  n  is  the  number  of  columns  in  table.name. 

*  Case  INSERT.RELATIONSHIP  obj.name  [  (  value.list  )  ]  BETWEEN 
reLobjJist 

— ►  INSERT  INTO  table.name  VALUES  (column.namei  =  valuei) 

for  1  <  i  <  n,  where  column.nam€i  includes  the  foreign  keys  of  the  related 

tables  mapped  from  reLobjJist. 

*  Case  DELETE-ENTITY  obj.name  (  predicate  ) 

— ►  DELETE  FROM  table.name  WHERE  predicate 
where  the  mapping  of  predicate  is  similar  to  that  in  condition  above  (with¬ 
out  the  IF  clause). 

*  Case  DELETE-RELATIONSHIP  obj.name  (  predicate  ) 

— »  DELETE  FROM  table.name  WHERE  predicate 
the  same  as  the  previous  case. 

*  Case  DELETE-RELATIONSHIP  obj.name  [  (  predicate  )  ]  BETWEEN 
rel.obj.list 

— *■  DELETE  FROM  table.name  WHERE  predicatci 

where  predicatei  includes  the  equality  condition  on  the  foreign  keys  of  the 

related  tables  mapped  from  reLobjJist. 

*  Case  MODIFY  obj.name  (  predicate  )  SET  (  value.list ) 

— ►  UPDATE  table.name  SET  (  column.namei  =  valuei  )  WHERE  pred- 
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icate 

for  1  <  i  <  n,  where  n  is  the  number  of  modified  attributes  of  obj.name; 
predicate  is  mapped  like  in  condition. 

*  Case  REJECT-OPERATION 
— ►  ROLLBACK  [  operation  ] 

where  operation  is  the  database  operation  associated  with  the  firing  event; 
operation  is  left  optional  for  the  case  in  which  the  target  DBMS  does 
not  support  rollback  at  operation  level.  Alternatively,  if  rollback  inside 
rules  is  not  supported  at  all  (e.g.  in  the  current  version  of  Ingres),  RE¬ 
JECT-OPERATION  maps  into  RAISE  ERROR  error#  :  message,  where 
message  is  a  mandatory  warning  to  the  user  or  application  that  originated 
the  firing  event. 

*  Case  PROPAGATE-OPERATION  (  db.eventJist  ) 

generates  a  sequence  of  operations  of  the  same  type  as  in  the  firing 
event.  The  propagation  is  performed  on  the  objects  explicitly  specified 
in  db.eventJist,  that  must  be  adjacent  to  the  firing  event  object  in  the  ER 
schema.  As  shown  before  (section  2.2.2),  the  propagation  does  not  cascade 
automatically  to  other,  non-adjacent  objects,  unless  additional  rules  are 
specified  that  deal  with  the  new  propagations.  The  tool  checks  the  adja¬ 
cency  by  invoking  the  meta-database  function  get.conn{obj.name)  where 
obj.name  is  the  name  of  the  event  object.  If  the  specified  list  is  correct, 
the  propagated  operations  are  generated: 

— ►  INSERT  INTO  table.name  VALUES  value.list 
— ►  DELETE  FROM  table.name  WHERE  predicate 
— ►  UPDATE  table.name  SET  value.list  WHERE  predicate,  where 
table.name  is  obtained  using  get.obj_map  {adjacent.obj.name),  while 
value.list  and  predicate  are  derived  from  the  firing  event  and  the  condi¬ 
tion  part  of  the  rule. 

*  Case  RAISE  event.id  :  signaLname  [  (  actual.parm.list  )  ] 

— ►  EXECUTE  PROCEDURE  signal.name[  (  actuaLparm.list )  ] 
assuming  that  a  signal  is  implemented  as  a  stored  procedure  (currently 
no  commercial  DBMS  has  such  functionality,  although  a  few  have  stored 
procedures). 

*  Case  MESSAGE  :  msg  [  (  event.id  :  signaLname  [  (  actual.parm.list )  ]  )  ] 
— *  message  =  msg]  MESSAGE  :  message] 

where  message  is  the  local  variable  keeping  the  text.  If  event.id  :  sig- 
naLname  [{actuaLparm.list)]  is  specified,  a  separate  procedure  containing 
the  MESSAGE  statement  is  created  to  emulate  the  signal. 

As  an  example,  the  behavior.sentence 

WHEN  eOl  :  EMPLOYEE  DELETED 
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FIRE  rOl  :  PROPAGATE-OPERATION  (  e02  :  DEPENDENT  DELETED, 
e03  :  Employed  DELETED,  e04  :  Manages  DELETED, 
e05  ;  Works  DELETED  ), 

MESSAGE  :  ’All  references  to  EMPLOYEE  being  deleted’, 
generates  the  following  DBMS  procedure/rule  definitions: 

CREATE  PROCEDURE  proc.r01 

(o_salary  float,  ojstat’\s  varchar,  o.birth.date  date,  o_address  varchar, 
o.job  varchar,  o_name  varchar,  o-ssn  char(9),  oJDEPARTMENTjiame 
varchar,  o-Employed-DEPARTMENT_name  varchar) 

AS  DECLARE  message  VARCHAR  NOT  NULL;  counter  INTEGER; 

BEGIN 

SELECT  COUNT(*)  INTO  counter  FROM  Works 
WHERE  EMPLOYEE^sn  =  ;ojsn; 

IF  counter  >  0 

THEN  DELETE  FROM  Works 

WHERE  EMPLOYEE^sn  =  :o^sn; 

ENDIF; 

SELECT  COUNT(*)  INTO  counter  FROM  DEPENDENT 
WHERE  EMPLOYEE^sn  =  :oo^sn; 

IF  counter  >  0 

THEN  DELETE  FROM  DEPENDENT 

WHERE  EMPLOYEE^sn  =  :o-ssn; 

ENDIF; 

message  =  ’All  references  to  EMPLOYEE  being  deleted’; 

MESSAGE  rmessage; 

END; 

CREATE  RULE  rOl  AFTER  DELETE  FROM  EMPLOYEE 
EXECUTE  PROCEDURE  proc-rOl 

(o_salary  =  old.salary,  o^tatus  =  old.status,  o.birth.date  =  old.birth.date, 
©.address  =  old.address,  o.job  =  old.job,  ojiame  =  old.name, 
o.ssn  =  old.ssn,  oJ)EPARTMENTjiame  =  old.DEPARTMENTjiame, 
oJimployed.DEPARTMENTjiame  =  old.Employed.DEPARTMENTjiame); 


This  example  also  illustrates  the  mapping  of  different  objects  into  the  same  table  (EM¬ 
PLOYEE,  Employed,  Manages  into  EMPLOYEE),  as  well  as  attributes  to  columns  and  how 
the  active  behavior  mapping  process  takes  advemtage  of  the  information  on  the  schema  trans¬ 
lation  to  generate  the  definition  of  rules  and  procedures  in  the  target  DBMS. 

The  mapping  process  described  above  is  direct,  i.e.,  it  translates  the  behavior  definition 
into  the  specification  of  procedures  and  rules  in  the  target  DBMS  without  attempting  to 


34 


generate  the  most  efficient  specification.  Like  other  SQL  constructs,  rules  and  procedures 
can  be  correctly  specified  in  various  ways;  optimization  issues  have  to  be  addressed  after  the 
translation,  with  the  generated  specification  as  the  starting  point. 

An  example  of  possible  further  optimization  is  the  evaluation  of  set-oriented  predicates. 
The  condition  part  of  a  rule  can  be  split  into  two  sets  of  predicates:  one  referring  to  the  object 
affected  by  the  firing  event,  and  the  other  containing  the  remaining  predicates.  The  first  set 
can  be  specified  in  the  WHERE  qualification  clause  of  the  rule,  outside  the  procedure  that 
evaluates  the  remaining  predicates.  This  splitting  restricts  the  amount  of  data  passed  to  the 
procedure,  making  its  execution  more  efficient. 

2.5  Summary 

In  summary,  in  this  section  we  described  the  (ER)^  model.  First,  we  introduced  events  and 
rules  as  objects  of  the  model  and  presented  a  syntax  for  the  specification  of  active  database 
behavior  using  events  and  rules.  Then  we  described  the  model  using  the  ER  formalism  and 
derived  a  semantics  of  the  active  behavior  specification  language  based  on  the  operational 
semantics  of  the  action  part  of  the  rules.  We  introduced  (ER)*  diagrams,  in  which  events 
and  rules  are  represented  along  with  entities  and  relationships,  as  a  graphical  tool  to  help  the 
database  designer  in  the  specification  of  active  behavior.  Finally  we  described  the  mapping 
of  the  active  constructs  in  the  (ER)^  schema  specification  into  DBMS  rules  and  stored  proce¬ 
dures.  The  mapping  algorithms  are  intended  for  use  by  a  translation  tool  that  automatically 
generates  the  executable  DBMS  language  statements  corresponding  to  the  active  behavior 
specified  in  the  (ER)^  schema. 
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Section  3 

CONSTRAINT  MODELING  AS  ACTIVE  DATABASE 
BEHAVIOR 


When  dealing  with  database  constraints  within  the  ER  model,  the  main  issue  is  the  mis¬ 
match  between  constraints  specification  and  enforcement:  while  specification  of  constraints 
has  a  declarative  nature,  their  enforcement  requires  procedural  language  constructs.  The 
relational  model  has  a  few  inherent  constraints  such  as  the  key  constraint  and  referential  in¬ 
tegrity  constraints  based  on  foreign  keys.  However,  there  is  no  such  general  mechanism  like  a 
constraint  enforcement  subsystem  in  a  DBMS  that  automatically  enforces  semantic  integrity 
of  the  database  without  the  need  of  writing  constraint-checking  statements  in  the  transac¬ 
tions.  In  section  3.1  we  show  that  the  (ER)^  approach  combined  with  the  active  database 
language  constructs  in  the  DBMS  is  also  useful  for  the  specification  and  translation  of  in¬ 
tegrity  constraints.  This  is  a  typical  internal  application  of  the  active  database  paradigm  that 
benefits  the  database  system  services.  In  particular,  we  show  in  section  3.2  that  the  inherent 
and  implicit  constraints  of  the  model,  also  known  as  invariant  properties,  can  be  mapped  into 
(ER)^  schema  specification  as  meta- behaviors,  and  translated  into  triggers  and  event  alerters 
that  will  enforce  their  preservation.  In  section  3.3,  we  show  that  dynamic  constraints,  which 
require  consistency  checking  of  database  state  transitions  as  opposed  to  individual  states,  are 
usually  better  specified  directly  in  the  active  behavior  specification  language. 


3.1  Integrity  Constraints 

Two  solutions  are  used  to  enforce  integrity  constraints  during  update  operations  on  the 
database.  The  first  solution  is  to  prevent  the  execution  of  constraint-violating  operations 
(rejection  strategy),  and  the  second  solution  is  to  permit  all  correct  operations  and  propagate 
them  to  related  objects,  if  necessary  for  preserving  the  integrity  of  the  database  (propagation 
strategy). 

Definition:  A  constraint  is  a  predicate  that  must  be  satisfied  at  all  time  during  the  existence 
of  the  database. 

Basically,  a  constraint  is  a  predicate  similar  to  the  type  used  to  specify  the  condition  part 
of  a  rule.  We  use  the  following  syntax: 
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constraint 

constrainLid 


constrainLid  predicate  .list 

identifier 


where  constrainLid  is  a  unique  identification  of  the  constraint  and  predicate.list  is  the  same 
as  defined  for  the  condition  part  of  a  rule. 

For  example, 

cl  :  salary  of  EMPLOYEE  >  10,000 

is  a  simple  constraint  that  restricts  the  vjilues  of  the  salaries  of  employees  in  a  way  that 
is  not  usually  representable  in  the  conceptual  schema.  Potential  violating  events  (i.e.,  the 
operations  that  cause  the  events)  are  the  insertion  of  an  employee  and  the  modification  of 
the  salary  of  an  employee.  Hence  some  enforcement  action,  either  a  rejection  or  a  correction, 
must  be  performed  when  such  events  are  detected  and  if  the  outcome  is  an  invalid  salary. 
This  behavior  is  exactly  the  active  database  behavior  in  the  form  of  events  and  rules. 

As  another  example, 

c2  :  salary  of  EMPLOYEE  <  salary  of  manager  AND 

DEPARTMENT-name  of  manager  =  DEPARTMENT_name  of  employer  AND 
EMPLOYEE-ssn  of  Employed  =  ssn  of  EMPLOYEE 

is  a  constraint  that  restricts  the  salaries  of  employees  to  be  less  than  the  salary  of  the  manager 
of  the  department  in  which  they  are  employed.  The  potential  constraint-violating  events  in 
this  case  are  any  modification  on  salary  or  insertion  of  an  employee  with  a  salary  and  any 
changes  on  the  “Manages”  or  “Employed”  relationship  caused  by  insertion  or  modification. 

The  active  database  behavior  derived  from  the  specification  of  static  constraints  as  in 
these  examples  requires  the  following  information  to  be  completely  defined: 

•  The  potential  constraint-violating  events,  each  of  which  will  become  the  event  part  of 
an  active  behavior. 

•  The  invalid  new  database  state  generated  by  the  violating  events,  which  will  become 
the  condition  part  of  the  rule. 

•  The  list  of  constraint-enforcing  actions  to  be  performed  when  each  violating  event  is 
detected  and  if  the  new  database  state  is  invalid.  This  list  will  become  the  action.list 
of  the  rule. 

In  other  words,  each  potential  constraint-violating  ^’vent  will  derive  an  active  database 
behavior  with  the  following  general  format  that  can  be  generated  with  the  help  of  a  translation 
tool: 
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WHEN  event Jd 

1 

violating.event 

FIRE  ruleJd 

IF  invalid-database.state 

THEN  enforcing.action.list 

where  evenLid  and  rule-id  are  tool-generated  identifications  of  the  event  and  the  rule. 

This  derivation  is  not  completely  automatable,  because  the  enforcing.actionJist  depends 
on  the  enforcement  strategy  adopted  for  the  constraint;  also,  specification  of  user-defined 
messages  may  be  desirable  as  part  of  the  action  list.  Thus  a  tool  to  assist  the  constraint- 
to-behavior  mapping  process  would  have  an  automated  step,  i.e.,  the  generation  of  violat- 
ing-events  and  the  invalid-database.state  plus  an  interactive  step  in  which  the  user  (database 
designer)  specifies  the  enforcing.actionJist.  Figure  3.1  illustrates  this  process;  the  figure  also 
shows  another  possibly  automated  step,  the  translation  of  active  behavior  into  DML  language 
constructs  in  a  target  DBMS. 


Figure  3.1:  Interactive  Framework  for  Active  Behavior  Derivation  from  Constraints 

In  this  framework,  the  derivation  of  an  invalitLdatabase.state  is  straightforward:  the 
database  will  be  in  an  invalid  state  if  the  predicateJist  of  the  constraint  is  false.  As  a  conse¬ 
quence,  the  condition  part  becomes  the  negation  of  the  predicateJist 
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invalid-database. state 


NOT  (  predicateJist ). 


The  set  of  violating.events  is  derived  directly  from  the  syntactic  analysis  of  the  constraint. 
This  issue  is  thoroughly  examined  in  [CW90]  in  the  context  of  an  SQL-based  constraint 
language  that  includes  aggregate  functions  and  set  operations  and  rules  in  the  Star  burst  pro¬ 
totype  DBMS.  In  our  opinion,  there  is  a  trade-off  between  the  expressiveness  of  the  constraint 
language  and  the  simplicity  of  its  declarative  semantics.  The  constraint-to-behavior  mapping 
is  useful  because  behavior  is  procedural,  thus  more  difficult  to  understand  and  program.  If 
the  constraint  language  becomes  as  complex  as  the  behavior  language,  the  mapping  will  not 
be  useful  anymore,  because  the  behavior  will  have  to  be  specified  to  enforce  the  constraints 
anyway. 

The  following  mapping  rules  are  used  to  derive  the  violating.events  from  the  specification 
of  a  constraint: 

1.  For  each  attr.name  that  appears  in  a  predicate,  modification  of  the  corresponding  at¬ 
tribute  and  insertion  of  the  owner  of  the  attribute  {obj.name)  are  potential  violat¬ 
ing.events. 

2.  For  each  obj.name  that  appears  in  a  predicate,  modification  and  insertion  of  the  corre¬ 
sponding  object  are  potential  violating.events. 

In  the  above  first  example,  constraint  “cl”  generates  the  following  templates  of  active 
behavior: 

WHEN  [BEFORE]  el-cl  :  salary  OF  EMPLOYEE  MODIFIED 
FIRE  rl-cl  :  IF  NOT  (salary  OF  EMPLOYEE  >  10,000) 

THEN  enforcing.action.list. 

WHEN  [BEFORE]  e2-cl  :  EMPLOYEE  INSERTED 
FIRE  r2-cl  :  IF  NOT  (salary  OF  EMPLOYEE  >  10,000) 

THEN  enforcing.action.list. 


The  BEFORE  option  is  left  open  because  it  depends  on  what  the  user  wants  to  specify 
in  the  action  list.  A  rejection  strategy  will  require  the  event  being  detected  before  it  occurs, 
or,  alternatively,  the  rollback  of  the  operation  after  the  event  has  occurred.  A  propagation 
strategy  will  take  effect  after  the  event  occurs. 

In  the  second  example,  the  templates  generated  for  constraint  “c2”  are: 

WHEN  [BEFORE]  el-c2  :  salary  OF  EMPLOYEE  MODIFIED 
FIRE  rl-c2  :  IF  NOT  (salary  of  EMPLOYEE  <  salary  of  manager  AND 
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DEPARTMENT_name  of  manager  =  DEPARTMENT  jaame  of  employer  AND 
EMPLOYEE-Ssn  of  Employed  =  ssn  of  EMPLOYEE) 

THEN  enforcing.action.list. 

WHEN  (BEFORE]  e2-c2  :  salary  OF  manager  MODIFIED 

FIRE  r2-c2  ;  IF  NOT  (salary  of  EMPLOYEE  <  salary  of  manager  AND 

DEPARTMENT-name  of  manager  =  DEPARTMENT_name  of  employer  AND 
EMPLOYEE^sn  of  Employed  =  ssn  of  EMPLOYEE) 

THEN  enforcing.action.list. 

WHEN  [BEFORE]  l-c2  ;  EMPLOYEE  INSERTED 

FIRE  r3-c2  ;  IF  N(  (salary  of  EMPLOYEE  <  salary  of  manager  AND 

DEPARTMENT-name  of  manager  =  DEPARTMENT_name  of  employer  AND 
EMPLOYEE-ssn  of  Employed  =  ssn  of  EMPLOYEE) 

THEN  enforcing.action.list. 

WHEN  [BEFORE]  e4-c2  :  Manages  INSERTED 

FIRE  r4-c2  :  IF  NOT  (salary  of  EMPLOYEE  <  salary  of  manager  AND 

DEPARTMENT-name  of  manager  =  DEPARTMENT_name  of  employer  AND 
EMPLOYEE-ssn  of  Employed  =  ssn  of  EMPLOYEE) 

THEN  enforcing.actionJist. 

WHEN  (BEFORE]  e5-c2  :  DEPARTMENT-name  OF  Manages  MODIFIED 

FIRE  r5-c2  :  IF  NOT  (salary  of  EMPLOYEE  <  salary  of  manager  AND 

DEPARTMENT-naiue  of  manager  =  DEPARTMENT-name  of  employer  AND 
EMPLOYEE-ssn  of  Employed  =  ssn  of  EMPLOYEE) 

THEN  enforcing.actionJist. 

WHEN  [BEFORE]  e6-c2  :  DEPARTMENT-name  OF  Employed  MODIFIED 

FIRE  r6-c2  :  IF  NOT  (salary  of  EMPLOYEE  <  salary  of  manager  AND 

DEPARTMENT-name  of  manager  =  DEPARTMENT-name  of  employer  AND 
EMPLOYEE-ssn  of  Employed  =  ssn  of  EMPLOYEE) 

THEN  enforcing.actionJist. 

WHEN  [BEFORE]  e7-c2  ;  Employed  INSERTED 

FIRE  r7-c2  :  IF  NOT  (salary  of  EMPLOYEE  <  salary  of  manager  AND 

DEPARTMENT-name  of  manager  =  DEPARTMENT-name  of  employer  AND 
EMPLOYEE-ssn  of  Employed  =  -  n  of  EMPLOYEE) 

THEN  enforcing.action.list. 

WHEN  [BEFORE]  e8-c2  :  EMPLOYEE-ssn  OF  Employed  MODIFIED 

FIRE  r8-c2  :  IF  NOT  (salary  of  EMPLOYEE  <  salary  of  manager  AND 
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DEPARTMENTjiame  of  manager  =  DEPARTMENT_name  of  employer  AND 
EMPLOYEEjsn  of  Employed  =  ssn  of  EMPLOYEE) 

THEN  enforcing.actionJist. 

WHEN  [BEFORE]  e9-c2  :  ssn  OF  EMPLOYEE  MODIFIED 

FIRE  r9-c2  :  IF  NOT  (salary  of  EMPLOYEE  <  salary  of  manager  AND 

DEPARTMENTjiame  of  manager  =  DEPARTMENT-name  of  employer  AND 
EMPLOYEE^sn  of  Employed  =  ssn  of  EMPLOYEE) 

THEN  enforcing.actionJist. 

The  latter  illustrates  an  interesting  aspect  of  the  model  that  was  addressed  in  sec¬ 
tion  2.4.  Recall  that  “manager”  (respectively  “employer”)  is  the  role  of  “EMPLOYEE” 
(respectively  “DEPARTMENT”)  in  the  relationship  “Manages”  (respectively  “Employed”), 
and  that  “salary”  is  an  attribute  of  “EMPLOYEE”  that  is  inherited  by  “Manages”  (respec¬ 
tively  “Employed”)  and  thus  by  “manager”  (respectively  “employer”).  In  addition,  “Man¬ 
ages”  (respectively  “Employed”)  is  usually  implemented  in  a  relational  database  as  a  column 
“Manages.DEPARTMENTjiame”  (respectively  “EmployedJDEPARTMENTjiame”)  in  the 
relation  “EMPLOYEE”,  i.e.,  the  semantic  links  provided  by  “Manages”  and  “Employed”  in 
the  ER  model  are  hidden  in  the  relational  model  in  the  form  of  foreign  keys.  This  information 
is  stored  in  the  meta-database  of  the  schema  design  and  is  used  for  optimizing  the  deriva¬ 
tion  of  behavior  templates  (e.g.  avoiding  redundancy  of  events  like  “salary  of  EMPLOYEE 
MODIFIED”  and  “salary  of  Manages  MODIFIED”).  It  is  also  used  to  translate  the  behavior 
specification  into  the  DBMS  triggers  or  event  alerters  (e.g.  mapping  “Employed  INSERTED” 
to  insertion  into  “EMPLOYEE”  relation). 

The  user  (database  designer)  needs  to  edit  the  templates  to  specify  the  “BEFORE”  clause 
of  the  event,  usually  necessary  with  rejection  actions,  and  the  enforcing.actionJist  for  each 
active  behavior.  The  generation  of  many  templates  of  active  behavior  for  a  single  constraint 
provides  modularity  and  flexibility  for  the  databjise  designer  to  specify  different  actions  for 
different  constraint- violating  events.  For  example,  it  might  be  the  user  intention  to  specify 
the  action  “REJECT-OPERATION”  for  rule  “rl-cl”  and  the  action  “MODIFY  EMPLOYEE 
SET  (salary  =  10,000)”  for  rule  “r2-cl”,  edthough  they  are  used  to  enforce  the  same  constraint. 

3.2  Invariant  Properties  of  the  Model 

The  ER  model  has  a  particular  set  of  static  constraints,  either  inherent  to  the  model  or 
implicit  in  the  schema  definition,  that  are  implied  by  the  invariant  properties  of  the  model. 

The  enforcement  of  these  constraints  can  be  specified  as  meta-behavior,  i.e.,  behavior  over 
the  meta-database,  and  automatically  generated  by  the  schema  design  and  translation  tool 
for  each  instance  of  object  types  or  attributes  in  the  meta-database  that  is  affected  by  the 
constraint- violating  events.  By  doing  this,  the  tool  relieves  the  database  designer  of  having  to 
specify  individual  active  database  behavior  for  each  affected  object  or  attribute.  Of  course, 
this  specification  must  be  regenerated  every  time  the  meta-database  changes,  i.e.,  every  time 
the  database  schema  evolves. 
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In  what  follows,  we  introduce  an  extension  to  the  notation  used  so  far  that  allows  us  to 
express  specification  of  meta-behavior  in  a  compact  form.  We  use  the  pseudo-expression  “For 
each”  to  denote  iteration  of  the  specification  through  the  sets  of  entity  and  relationship  types 
stored  in  the  meta-database.  Hence  the  following  meta-events  are  defined  over  the  ER  objects 
ENTITY  and  RELATIONSHIP;  each  meta-event  maps  into  a  set  of  events  in  a  given  actual 
database  schema: 

evl;  enLname  OF  ENTITY  INSERTED 

ev2:  enLname  OF  ENTITY  MODIFIED 

ev3;  enLname  OF  ENTITY  DELETED 

ev4;  reLname  OF  RELATIONSHIP  INSERTED 
ev5:  reLname  OF  RELATIONSHIP  MODIFIED 
ev6:  reLname  OF  RELATIONSHIP  DELETED 

Also,  the  following  meta-schemas  of  ENTITY  and  RELATIONSHIP  in  figure  2.1  are 
assumed. 

ENTITY  : 

ent_name  :  name  of  the  entity  type. 

key_attr_name()  :  key  attribute  of  the  entity  type.  The  notation  ()  means  that 
“key-attr-name”  can  be  composite. 

part_rel*(rel_name,  part_type)  :  set  of  relationship  types  which  the  entity  type  participates  in. 
The  notation  *  means  that  “part-rel”  can  be  multi-valued.  Each  “part-rel”  is  composed 
by  “rel_name”  (name  of  the  relationship  type),  and  “part.type”  of  relationship  (type  of 
participation  of  the  entity  type  in  the  relationship  type,  that  can  be  either  “Total”  or 
“Partial”). 

from_ent_conn*(ent_name,  conn.type)  :  set  of  connections  from  other  entity  types,  composed 
of  “entjiame”  and  “conn.type”,  that  can  be  either  “Is.A”  (specialization)  or  “ID” 
(identification  dependency). 

to_ent-conn*(ent  jiame,  conn.type)  :  set  of  connections  to  other  entity  types,  i.e.,  the  recip¬ 
rocal  of  “from-ent.conn”. 

RELATIONSHIP  : 

reljvame  :  name  of  the  relationship  type. 
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reLobj*(obj_name,  key.attr-name())  :  set  of  object  types  associated  by  the  relationship  type. 
Each  rel-obj  is  composed  by  “obj_name”  (name  of  the  related  entity  or  relationship 
type),  and  “key_attr_name()”  (key  attribute  of  the  entity  or  relationship  type). 

part_rer(rel_name,  type)  :  same  as  in  ENTITY.  Recall  that  we  allow  relationships  to  partic¬ 
ipate  in  relationships. 

The  actual  implementation  of  the  meta-database  may  have  a  different  meta-schema;  for 
example,  information  on  connections  between  object  types  are  usually  kept  as  meta-attributes 
of  the  meta- relationship  “ER  Connection”  (figure  2.2).  Here  we  assume  they  are  stored  also 
in  the  meta-objects  ENTITY  and  RELATIONSHIP,  in  order  to  facilitate  the  description  of 
conditions  and  actions  in  the  specification  of  the  meta- behaviors  that  enforce  the  invariant 
properties. 

In  addition,  we  use  a  notation  similar  to  that  used  in  the  description  of  the  semantics  of 
the  actions  (section  2.2.2)  to  describe  the  protocols  of  the  meta-behaviors.  “Pre-conditions” 
and  “Post-conditions”  are  defined  to  apply  the  rejection  strategy,  and  an  “Implies”  expression 
is  introduced  to  apply  the  propagation  strategy. 

1.  Key  constraint  (each  instance  of  an  entity  must  be  unique).  This  mapping  is  given  for  the 
sake  of  completeness:  the  key  constraint  is  supported  declaratively  and  automatically 
by  most  of  the  DBMSs. 

a.  INSERT  e,  INTO  Ei 
Pre-condition  :  ->3  e,  €  Ei 

For  each  ent_name  in  ENTITY  : 

WHEN  BEFORE  evl  :  ent_name  OF  ENTITY  INSERTED 
FIRE  rl-kc  :  IF  NEW  key_attrjiame  IN  SET.OF  (key-attr_name) 

THEN  REJECT.OPERATION, 

MESSAGE  :  “Key  attribute  already  exists”. 


b.  MODIFY  e.  IN  E, 

Post-condition  ;  new  key  .attribute  of  =  old  key  .attribute  of 

For  each  ent  Jiame  in  ENTITY  : 

WHEN  BEFORE  ev2  :  ent  Jiame  of  ENTITY  MODIFIED 
FIRE  r2-kc  :  IF  NEW  key.attrjiame  ^  OLD  key_attrjiame 
THEN  REJECT.OPERATION, 

MESSAGE  :  “Not  allowed  to  change  key  attribute”. 


2.  Relationship  referential  integrity  constraint  (a  relationship  can  exist  only  if  the  corre¬ 
sponding  related  objects  exist). 
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a.  INSERT  r  INTO  R  where  R{Eu  •••,  En) 

Pre-condition  :  3  €  Ei,  ei  =  Ei(r)  A 

...  A 

3  Cn  €  Ejit 

For  each  reLname  in  RELATIONSHIP  ; 

WHEN  BEFORE  ev4  :  reUame  OF  RELATIONSHIP  INSERTED 
FIRE  rl-ric  :  IF  NEW  reLobj.keyjittrjiame  NOT  IN  SET.OF 
(reLofaj.key^ttr-name) 

THEN  REJECT-OPERATION, 

MESSAGE  :  “Inexistent  related  entity”. 

b.  DELETE  ei  FROM  E, 

IM PLIES  G  Rie,)  DELETE  r  FROM  R 

For  each  ent.name  in  ENTITY  ; 

WHEN  ev3  :  ent.name  OF  ENTITY  DELETED 
FIRE  r2-ric  :  THEN  DELETE.RELATIONSHIP  part.iel.reLname 
(rel-obj.key-attr.name  =  OLD  key-attr-name)  (ev6). 

c.  DELETE  fi  FROM  Ri 

IMPLIES  V  r  e  R(r,)  DELETE  r  FROM  R 

For  each  reLname  in  RELATIONSHIP  : 

WHEN  ev6  ;  reLname  OF  RELATIONSHIP  DELETED 
FIRE  r3-ric  :  THEN  DELETE-RELATIONSHIP  part.reI.reLname 

(reLobj.key.attr-name  =  OLD  reLobj.key-attr.name)  (ev6). 

Note:  The  latter  behavior  is  necessary  because  we  allow  relationship  involving  rela¬ 
tionships.  Notice  that  key.attr_name  may  be  composite;  also,  notice  that  part_rel  and 
rel-obj  are  multi-valued.  As  a  consequence,  the  mapping  from  meta-behavior  to  actual 
behavior  will  require  multiple  iterations  through  the  sets  of  attributes  and  objects  for 
the  complete  specification  of  conditions  and  actions. 

3.  Total  participation  constraint  (if  the  relationship  is  total  on  an  entity,  then  the  existence 
of  the  related  entity  requires  the  existence  of  this  relationship). 

a.  INSERT  ei  INTO  Ei 

Pre-condition  :  3  R,  participation  of  Ei  in  R  is  total 
Post-condition  :  V  R,  participation  of  Ei  in  R  is  total,  e,-  =  Ei(r) 

For  each  ent  jiame  in  ENTITY  : 

WHEN  evl  :  entjiame  OF  ENTITY  INSERTED 
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FIRE  rl-tpc  :  IF  partjel.part.type  =  “Total” 

THEN  MESSAGE  : 

“Need  to  insert  mandatory  relationship  for  inserted  entity”. 

4.  Identification  dependency  constraint  (if  a  relationship  is  weak  on  an  entity,  then  the 
existence  of  the  weak  entity  requires  the  existence  of  the  related  strong  entity). 

a.  DELETE  e.  FROM  Ei 

IMPLIES  V  Cj  £  Ej,  Cj  is  ID  on  ei,  DELETE  e_,  FROM  Ej 

For  each  ent_name  in  ENTITY  : 

WHEN  ev3  :  entjiame  OF  ENTITY  DELETED 
FIRE  rl-idc  :  IF  from-ent_conn.conn_type  =  “ID” 

THEN  DELETE-ENTITY  from-ent_conn.ent_name 
(key_attr_name  OF  from_ent_conn.ent-name  = 

OLD  key_attr_name)  (ev3). 

b.  INSERT  e,  INTO  E, 

Pre-condition  :  e,  is  ID  on  Cj  — ►  3  6  Ej 

For  each  ent_name  in  ENTITY  : 

WHEN  evl  :  ent_name  of  ENTITY  INSERTED 
FIRE  r2-idc  ;  IF  to.ent.conn.conn-type  =  “ID”  AND 

key_attr_name  OF  to_ent-conn.ent_name  NOT  IN  SET.OF 
(key-attr-name  OF  entjiame) 

THEN  MESSAGE  : 

“Identification  dependency;  owner  entity  does  not  exist”. 


5.  Aggregation  referential  integrity  constraint  (an  aggregation  can  exist  only  if  the  corre¬ 
sponding  components  exist). 

This  property  is  enforced  by  the  relationship  referential  integrity  constraint  (property 
2),  since  we  consider  a  relationship  as  an  aggregation  of  the  participant  entities  to  allow 
relationships  involving  relationships  (fuU  aggregation). 

6.  Superclass  completeness  constraint  (a  specialization  is  total  on  a  generalization,  i.e.  the 
existence  of  a  specialization  requires  the  existence  of  its  generalization). 

a.  INSERT  Ci  INTO  Ei 

Pre-condition  :  Ei  is  a  sub  -  class  of  Ej  — ►  3  €  Ej 

For  each  ent_name  in  ENTITY  : 

WHEN  evl  :  entjiame  OF  ENTITY  INSERTED 
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FIRE  rl-scc  ;  IF  to.ent.conn.conn.type  =  “Is_A”  AND 

key.attr-name  OF  to.ent .conn. ent .name  NOT  IN  SET.OF 
(key_attr_narae  OF  ent-name) 

THEN  MESSAGE  : 

“Specialization:  generic  entity  does  not  exist”, 
b.  DELETE  ei  FROM  E, 

IMPLIES  V  Ej  sub  -  class  of  DELETE  e.  FROM  E, 

For  each  entjiame  in  ENTITY  : 

WHEN  ev3  :  ent  jiame  of  ENTITY  DELETED 

FIRE  r2-scc  :  IF  from.ent.conn.conn_type  =  “Is_A” 

THEN  DELETE-ENTITY  from_ent_conn .ent -name 
(key-attr-name  OF  from-ent-conn.ent-name  = 

OLD  key-attr-name)  (ev3). 

In  the  above,  we  applied  both  the  rejection  and  the  update  strategies  for  deri^'!ng  meta¬ 
behaviors  to  enforce  inherent  and  implicit  constraints  of  the  model.  The  translation  tool  can 
be  tailored  to  support  the  generation  of  other  active  database  behaviors  that  enforce  more 
specific  invariant  properties  like  superclass  completeness,  subclass  disjointness,  or  relationship 
cardinality  constraints.  In  addition,  a  more  complex  constraint-checking  behavior  can  be 
generated  using  aggregate  predicates,  such  as:  “When  a  relationship  is  deleted,  if  some  entity 
type  participation  is  total  on  it  and  the  deleted  relationship  is  the  last  one  for  the  related 
entity,  then  send  a  message  to  the  user,  or,  alternatively,  propagate  the  deletion  to  the  related 
entity.”  All  these  meta-behaviors  embedded  in  the  translation  tool  can  be  left  ais  optional 
so  that  the  user  decides  at  design  time  which  set  of  invariant  properties  is  desirable  to  be 
considered  for  a  given  application  and  which  strategy  to  apply  in  order  to  enforce  them. 
Figure  3.2  illustrates  the  meta- behaviors  specified  in  this  section  2is  a  meta-(ER)^-diagram  of 
the  ER  model  and  its  invariant  properties. 


3.3  Dynamic  Constraints 

The  inherent  and  implicit  constraints  implied  by  the  invariant  properties  of  the  data  model, 
as  well  as  the  explicit  constraints  exemplified  in  section  3.1,  are  constraints  that  must  hold 
in  every  state  of  the  database.  They  are  called  static  constraints  because  they  deal  with  the 
consistency  of  a  single  database  state. 

Some  explicit  constraints  deal  with  the  consistency  of  transitions  of  database  states  and  are 
called  dynamic  constraints.  Their  specification  usually  requires  very  high  level  predicates  that 
are  not  expressible  in  declarative  constraint  languages.  Since  they  occur  less  frequently  than 
static  constraints,  it  is  easier  to  specify  dynamic  constraints  procedurally  as  active  database 
behaviors,  rather  than  augmenting  the  constraint  specification  language  to  capture  multiple 
database  states. 
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As  an  example,  “the  salary  of  an  engineer  cannot  decrease”  is  a  constraint  that  requires 
checking  the  database  states  before  and  after  an  update  on  “salary  of  EMPLOYEE”  is  per¬ 
formed.  Instead  of  trying  to  specify  such  constraint  in  a  rich  constraint  specification  language 
and  then  translating  it  into  the  procedural  constructs  that  will  enforce  it,  the  following  active 
database  behavior  is  easily  derived  from  the  semantics  of  the  constraint: 

WHEN  el-dc  ;  salary  OF  EMPLOYEE  MODIFIED 
FIRE  rl-dc  :  IF  OLD  job  =  “engineer”  AND  NEW  salary  <  OLD  salary 
THEN  MESSAGE  :  “Engineers’  salaries  cannot  decrease”, 
REJECT.OPERATION. 

3.4  Summary 

As  a  summary,  in  this  section  we  have  shown  the  application  of  the  active  database  behavior 
to  enforce  integrity  constraints.  The  following  conclusions  are  derived  : 

1.  Static  constraints 

(a)  If  inherent  to  the  data  model  or  implicit  in  the  conceptual  schema,  i.e.,  implied 
by  the  invariant  properties  of  the  model,  they  can  be  specified  as  meta-behaviors. 
The  schema  translation  tool  will  instantiate  each  meta-behavior  as  actual  behavior 
in  the  given  database  and  translate  them  into  the  language  constructs  (rules  or 
triggers)  in  the  target  DBMS. 

(b)  If  explicit  constraints,  i.e.,  constraints  of  the  application  semantics  (business  rules), 
they  can  derive  active  database  behavior  by  means  of  an  interactive  tool  that  gen¬ 
erates  templates  of  behavior  specification  and  then  accepts  user  intervention  to 
complete  the  specification.  For  very  complex  application  constraints,  the  con¬ 
straint  definition  may  require  very  complicated  predicates,  and  the  mapping  pro¬ 
cess  may  not  be  worthwhile,  because  the  constraint-enforcing  active  behavior  must 
be  specified  anyway. 

2.  Dynamic  constraints 

These  are  always  explicit,  application-oriented  constraints.  They  are  better  specified 
directly  in  the  form  of  the  active  behavior  that  will  enforce  them. 
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Section  4 


CONCLUSION  AND  FUTURE  DIRECTION 


Our  claim  is  that  the  lack  of  modeling  constructs  for  active  database  capabilities  present  in 
the  new  generation  of  relational  DBMSs  has  made  it  difficult  to  take  full  advantage  of  their 
potential  benefits.  The  current  database  design  methodology  forces  the  user  to  defer  critical 
modeling  decisions  concerning  the  active  behavior  of  the  database  to  late  stages  of  the  design 
process,  where  the  semantics  of  the  real-world  situations  are  obscured  by  the  intricacies  of 
the  implementation  model.  Because  of  the  inherent  complexity  of  rule-based  programming, 
database  designers  do  not  exploit  adequately  the  functionalities  of  rules,  triggers  and  stored 
procedures.  Furthermore,  it  is  expected  that  more  powerful  active  capabilities  will  be  added  to 
the  DBMSs  by  demand  of  non-conventional  database  applications,  enlarging  the  gap  between 
modeling  and  specification  of  executable  definitions  of  active  behavior. 

Our  approach  to  this  problem  was  to  extend  the  well-established  methodology  based  on 
the  ER  model  by  incorporating  active  database  behavior  in  the  form  of  events  and  rules  as 
first-class  objects  of  the  model. 

The  following  benefits  will  result  from  the  extended  modeling  and  design  methodology: 
reduced  database  design  and  application  development  effort  with  the  automatic  generation  of 
meta-behavior  and  translation  of  active  behavior  into  executable  DBMS  language  constructs; 
better  control  of  the  development  of  database  applications;  and  better  quality  of  the  overall 
design.  In  the  present  report,  we  have  concentrated  on  the  modeling  of  the  active  behavior 
and  a  specification  of  the  constraints.  Further  details  of  the  design  methodology  for  active 
databases  can  be  found  in  [Tan92]. 


4.1  Summary 

We  introduced  the  (ER)^  model  as  a  uniform  way  to  express  active  database  behavior  along 
with  entities  and  relationships.  We  .  oarated  the  concepts  of  an  event  and  the  action  that 
causes  its  occurrence,  many  times  considered  as  the  same  fact  in  other  approaches.  We  also 
differentiated  events  and  conditions,  because  although  they  both  represent  predicates  and  are 
so  modeled  in  some  dynamic  modeling  approaches,  they  have  different  semantics  and  timing 
of  occurrence  and  evaluation.  With  these  distinctions,  we  were  able  to  define  both  events 
and  rules  as  objects  of  the  model,  rather  than  only  rules  ais  considered  in  the  literature  so 
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far.  We  identified  attributes  of  events  and  rules  and  characterized  classes  and  instances  of 
events  and  rules.  We  also  identified  the  inter-event  and  inter-rule  connections,  as  well  as 
the  semantic  connections  between  events  and  rules,  and  between  events  and  data  objects 
or  the  external  environment.  Based  on  these  modeling  concepts  and  the  ER  formalism,  a 
set-oriented  syntax  and  semantics  for  active  database  behavior  was  defined.  We  proposed  a 
diagrammatic  representation  of  active  behavior  in  terms  of  events  and  rules,  as  an  extension 
to  ER  diagrams.  We  showed  that  with  the  provision  of  a  meta-database  of  the  design,  the 
translation  of  active  database  behavior  from  the  (ER)^  model  to  commercial  relational  DBMSs 
can  be  easily  incorporated  into  the  database  design  process,  relieving  the  user  from  the  need 
to  program  rules,  triggers  and  procedures  for  enforcing  that  behavior. 

Next  we  showed  that  constraint  maintenance  can  be  achieved  by  specifying  constraints 
declaratively  and  deriving  appropriate  event-condition-action  behavior  that  in  effect  imple¬ 
ment  those  constructs.  This  transformation  is  useful  for  the  types  of  constraints  that,  although 
enforced  procedarally  by  th  '*  DBMS,  are  easier  to  specify  declaratively.  From  these,  one  can 
derive  a  set  of  procedures  and  rules  to  enforce  them.  Dynamic  constraints,  which  refer  to  the 
consistency  of  state  transitions  rather  than  to  a  single  state,  were  shown  to  be  more  easily 
specified  directly  in  terms  of  an  active  behavior  instead  of  trying  to  extend  the  constraint 
language  to  consider  multiple  states.  A  special  type  of  constraint,  which  is  implied  by  the 
invariant  properties  of  the  ER  model,  if  not  supported  declaratively  by  the  DBMS,  can  be 
specified  by  means  of  a  meta- behavior,  i.e.,  behavior  over  all  entity  sets  and  all  relationship 
sets  and  instantiated  to  appropriate  instances  of  actual  active  behaviors  by  the  design  and 
translation  tool  for  a  particular  populated  database. 

4.2  Further  Research  and  Development 

Supplementary  research  and  development  is  needed  to  take  full  advantage  of  the  benefits 
that  accrue  to  databases  by  the  incorporation  of  active  capabilities.  Some  major  research 
directions  are  listed  below: 

•  It  is  necessary  to  combin'*  data,  control,  and  process  modeling  to  capture  active  database 
behavior  and  application  transactions  in  the  same  model. 

•  As  a  consequence,  the  interaction  of  rule  processing  and  transaction  processing  in  the 
execution  model  of  an  active  database  must  be  considered  to  provide  the  database 
designer  with  a  complete  analysis  model,  in  which  the  whole  behavior  of  the  database 
can  be  validated. 

•  A  declarative  constraint  specification  language  using  constraints  as  predicates  at  the 
conceptual  level,  for  enforcing  constraints  as  active  behaviors. 

•  An  architecture  of  tools  has  been  proposed  to  incorporate  the  active  database  exten¬ 
sion  into  current  relational  database  methodology  [NTC93].  These  tools  need  to  be 
implemented. 
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•  A  graphical  interface  for  specification  of  events  and  rules,  either  integrated  with  an  ER 
diagramming  tool  or  in  a  separate  editor  is  needed.  Also,  a  validation  tool  based  on  a 
high  level  Petri  net  editor/simulator,  possibly  taking  advantage  of  the  analysis  methods 
developed  for  hierarchical  high-level  Petri  nets  [Jen91]  would  be  desirable. 

Furthermore,  the  research  on  active  databases  is  raising  new  issues  and  discovering  new 
applications;  some  of  them  will  also  impact  modeling  and  design  : 

•  Deductive  databases  as  a  class  of  active  databases:  a  deductive  rule  can  be  seen  as  an 
active  behavior,  where  there  is  no  event  (or  it  is  just  a  retrieval),  and  the  condition- 
action  pair  is  a  deduction  rather  than  an  operation  on  the  database  or  a  message.  Since 
the  active  database  paradigm  subsumes  the  deductive  database  paradigm,  both  could 
be  present  in  actual  DBMSs,  providing  a  platform  for  large  knowledge  bases  and  expert 
systems  [SKdM92]. 

•  Rules  in  00  DBMSs:  the  00  paradigm  seems  to  be  a  natural  way  to  accommodate 
active  behavior  in  the  form  of  events  and  rules  as  first-class  objects.  The  availability  of 
efficient  implementations  of  rules  in  00  DBMSs  is  expected  and  will  impact  the  way 
active  database  behavior  is  modeled  and  designed  [DPG91]. 

•  Parallel  and  distributed  active  databases:  rule  processing  is  usually  performed  in  a 
centralized,  sequential  fashion.  Given  the  high  interest  in  parallel  and  distributed  envi¬ 
ronments,  it  is  important  for  active  databases  to  be  adapted  to  them  [CW92]. 

•  Database  authorization  schema:  the  active  database  paradigm  is  clearly  a  real  alterna¬ 
tive  for  database  security,  and  much  work  has  to  be  done  in  this  area  [Lun92]. 

•  Derived  data  maintenance:  it  is  widely  recognized  that  the  active  database  paradigm  can 
be  used  to  automatically  maintain  derived  data  such  as  views.  Research  on  design  and 
analysis  of  active  behavior  for  efficiently  maintaining  derived  data  is  on-going  [CW91]. 

•  Schema  evolution:  automatic  propagation  of  changes  in  the  schema  can  be  performed 
using  the  active  database  paradigm,  especially  by  taking  advantage  of  the  meta-database 
that  describes  the  database  and  its  design  process  [MR90]. 

•  Reverse  engineering  of  legacy  systems:  in  spite  of  the  wide  acceptance  of  relational 
database  technology,  most  of  the  corporate  data  is  currently  stored  in  large  data  repos¬ 
itories  residing  in  flat  files.  Reverse  engineering  of  these  old  systems  is  a  key  research 
area,  and  the  active  database  paradigm  can  play  an  important  role  in  the  knowledge 
discovery  of  business  rules. 
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